RustConf 2026 presentation transcript

For those who missed my RustConf lightning talk, here's my slides and nearly what I said. Once the recording is available, I'll link it here.

Using Rust's std on high-end MCUs

Hey folks, my name is Ian McIntyre. I'm an embedded software engineer. For the past 6 years, I've helped bring Rust to some high-end microcontrollers (MCUs) through the open source imxrt-rs project, all without the standard library.

Photo Slide: Collection of i.MX RT development boards

Here's examples of boards you can build around these MCUs. These kinds of MCUs do not have the hardware to support a traditional operating system, making it harder to use the Rust standard library. Nevertheless, they have plenty of computing power and I/O, and they can be externally customized with more resources.

Photo Slide: 1180EVK block diagram

To give you a sense of available resources, let's look at the top-left board. The MCU on this board has two cores: one running at 800MHz, and the other at 300MHz. There's 1.5 megabytes of on-chip RAM. Already, that's a decent amout of compute and RAM to run an application and support software.

Then, you can add external RAM, if your application needs it.

These MCUs don't come with flash, so you add it, sized for your application. You could use flash for persistence, realizing a file system. You can also execute instructions from this external flash.

Finally, this MCU has up to five Ethernet ports, just in case you need that much connectivity.

That's a complex embedded platform, requiring plenty of systems software to make usable. And besides the resources we covered, we haven't considered anything else managed by this system, like its sensors or actuators.

Do you need the Rust standard library? No!
We usually use no_std Rust.

Could you use it? Probably.
Would it be fun? I think so.

As someone using Rust for embedded systems, I usually don't need the Rust standard library to take advantage of these high-end MCUs. It takes more work, but it's do-able.

But, I also think these platforms have enough resources to support the standard library, if it were available. And if available, I think it would be easier for everyone, including me, to use Rust in these kinds of places. I also think it would be fun to use, or just to try it out! So I'm giving it a shot.

Plan

1. Select ThreadX as OS foundation
2. Develop safer, no_std Rust
3. Use bindings to implement Rust's std
4. Develop drivers using safer, no_std bindings
5. Create apps with Rust's std

In order to use the things expected by the standard library, you need some kind of a runtime, or an operating system. I'm not building my own operating system right now. Instead, I selected ThreadX as the foundation. It's an open source, portable operating system with a straightforward build system and API.

Since ThreadX only has a C interface, I'm developing safer, no_std Rust bindings for ThreadX. These bindings make it easier to implement Rust's standard library. And if this doesn't work out, at least I'll have something I could still use without the standard library.

Separately, I'm developing hardware integrations using the safer, no_std bindings. This includes things like the network driver, low-speed peripheral drivers, and the other things you'd expect to be supported by your embedded system.

Finally, when all that's done, we can build applications that use the standard library.

What's done so far?

• std mods: thread, sync, alloc, time
  • net is WIP
• ENET driver for i.MX RT MCUs
• Hardware support packages
  • QEMU (ARM)
  • Teensy 4, iMXRT1170EVK
• no_std ThreadX bindings

It's working so far. The ThreadX standard library port supports threading, synchronization primitives, alloc, and time. Network support is limited to basic UDP sockets; I'm still working on it. Nevertheless, the ENET driver works without the Rust standard library, supporting IPv4, TCP, and UDP.

I have a few hardware support packages. I have QEMU support, allowing you to emulate an embedded system on your host. And I have packages for some of the boards on the previous slide. After I submitted my slides, I implemented support for the Raspberry Pi Pico boards and associated MCUs.

use std::time::Duration;

// Just one magic import!
use rust_threadx_your_hardware as _;

fn main() {
    let mut count = 0_usize;
    loop {
        std::thread::sleep(Duration::from_millis(500));
        println!("Hello world! The count is {count}");
        count = count.wrapping_add(1);
    }
}

Here's what it looks like to write a simple hello world application. The only special thing you need is a magic import, and a dependency on that hardware package. That package coordinates with the standard library to initialize your hardware and software drivers, before main() runs. These packages are maintained outside the standard library, making it easy to port the project to new platforms.

The hardware package hides things like the network driver setup. Although I'm still working on the net module, early iperf benchmarking of the i.MX RT ENET driver shows that it's achieving 95% of its expected throughput. Once I'm finished with standard library integration, that performance should be available for your apps.

std port	NuttX	esp-idf	ThreadX
Supported targets	ARM, RISC-V, x86	Espressif MCUs (vendor specific)	ARM, RISC-V
Kernel / runtime language	C	C (FreeRTOS)	C
Language for drivers	C (in kernel)	C (in SDK)	Rust, you write them!
Build tooling	make / CMake (app built with kernel)	cargo	cargo

There are other approaches for using the Rust standard library on MCUs. You could use NuttX, another real-time operating system, or development tools provided by certain MCU vendors. Like those approach, my approach relies on an operating system written in C. However, when compared to those approaches, I get to write my hardware drivers in Rust, and applications are built with Cargo, like you're used to.

Download the toolchain, examples, and support libraries.

The project is open source. Check out my website for all the things I covered. Thanks for listening!