Home > On-Demand Archives > Talks >

Rust for Embedded Developers: The Peripheral Access Crate

Jacob Beningo - Watch Now - EOC 2024 - Duration: 46:16

Rust for Embedded Developers: The Peripheral Access Crate
Jacob Beningo

The C programming language has dominated embedded software development for the last 50 years. Despite other languages coming and going, C has withstood the winds of change. The latest language to challenge C’s dominance is Rust. Rust is a system programming language offering modern features, including memory safety.

In this session, we will explore the Rust programming language from an embedded developer’s perspective. We will look at the peripheral access crate (PAC), and examine how to develop low-level drivers. As an example, we’ll look at creating a blinky hello world application and then move on to a serial peripheral driver. Attendees will walk away, understanding the advantages and disadvantages of using Rust in an embedded system.

Topics covered in this talk will include:

  • The Peripheral Access Crate (PAC)
  • How to create a PAC
  • Advantages and Disadvantages of Rust in embedded systems
  • Rust fundamentals
  • How Rust fits into the industry in the big picture
M↓ MARKDOWN HELP
italicssurround text with
*asterisks*
boldsurround text with
**two asterisks**
hyperlink
[hyperlink](https://example.com)
or just a bare URL
code
surround text with
`backticks`
strikethroughsurround text with
~~two tilde characters~~
quote
prefix with
>

GlebPlekhotko
Score: 0 | 5 months ago | 1 reply

Thank you for sharing your thoughts!

I started to look at Rust a couple of years ago. First, because I wanted to put something beside C/C++ in my pocket, and second, because of the hype. All that fuss about the "fast, reliable, safe super-language of the future", you know. :-) In the end, it became my "weekend toy" for PC. Write a little project here, a piece of code there, become surprised things are not going the way they go in the venerable C. That sort of stuff.

Personally, I don't think Rust will overrun the C/C++ in the deeply embedded application. Ones, where programmer deals with the registers and memories directly and where it is the most natural way to get the job done. Just because these are inherently unsafe operations, which Rust tries to prevent. Trying to write code in the "Rust way" simply makes it more verbose and harder to understand, while some special "crates" aimed to mitigate Rust's restrictions or numerous "unsafe" sections will simply break the philosophy of the language. What's the point of using the "safe" language in the "unsafe" way, right?

At first glance, it seems to be full of useful features, and some of them really are (modules/namespaces, "impl" blocks for structures) etc. While others, in the end, rendered to be confusing and questionable. For instance, the enumerations, which cannot be easily cast to integers. Or strings, which are UTF-8 encoded, and there are some peculiarities when indexing them. Maybe the GUI-reach applications really need the fancy encoding, but a debug console/terminal, where just the first half of the ASCII table is used, definitely does not. And many, many others. Maybe it is my C bias, and I just need to think in the "Rust way", but sometimes it ticks off.

And some features, if scrutinized, become a significant problem. Another example is the "crate" concept. It is very convenient when you don't need to supply the compiler all those paths to header files, source files and so on. Just feed it the crate's root, and it will reach the very last module automatically using the naming convention. But what should I do if I'm running the unit tests and I want to substitute some dependencies with the mocks? Copy module to an auxiliary project to test it there? But what about the built-in testing support? I haven't found the answer to that question yet. Maybe it is buried somewhere deep in the "rustc" or "cargo" documentation and I just need to spend a few more hours (or days) searching. :-)

But don't get me wrong, I'm not telling it is a flawed language. It is definitely interesting, has its own advantages, and quite possibly will find its way into mainstream development, or at least a certain niece. But currently, it poses a challenge for a "classic" embedded programmer. Maybe that will change in the future. Or maybe it will decline like the Ada. That we will see.

Of course, that's just a humble opinion of a very regular developer. :-)

Jacob_BeningoSpeaker
Score: 0 | 5 months ago | no reply

Thanks for sharing! I don't disagree on many points. I think that we will also find that mixed languages will be a solution for the future. Using low-level C for the "unsafe" pieces and register interactions and then using Rust for the high-level application.

We'll see. I'm still very partial to C++, but I'm finding Rust to be quite interesting.

michaelHouse
Score: 0 | 7 months ago | 1 reply

While I enjoy coding in Rust, from this video my impression is Rust support for microcontrollers is really only prime for STM32. My quick search for Rust on PIC16 and Arduino leads me to believe it wouldn't be worth the effort.

Jacob_BeningoSpeaker
Score: 0 | 7 months ago | no reply

Thanks for the comment. I've honestly not tried on anything other than Arm Cortex-M microcontrollers. The example I've used is for STM32, but other Cortex-M parts are supported as well.

MarkBremer
Score: 0 | 7 months ago | 1 reply

I think your explanation of a crate isn't quite right. A crate can contain multiple .rs files and is more similar to a library. Crates can contain multiple modules, which is closer to what you're explaining, where each .rs file is, by default, a single module (you can also define multiple modules in a single file if you'd like).

Jacob_BeningoSpeaker
Score: 0 | 7 months ago | 1 reply

Thanks for the comment. I think the language is a bit ambiguous.
A quick search I found this:

In Rust, a crate is a compilation unit, which can be thought of as a package or a library. It is the fundamental building block of a Rust project, similar to a package in other programming languages.

So an individual .rs file can be considered a crate. However, if you a project that will be used as a library or package, that could also be considered a crate.

So in my example, we had many .rs files in that we compiled into a single library crate for the L475. Then we used that single crate in a project that had a single .rs file.

I agree I could have been more clear on the definition!

MarkBremer
Score: 0 | 7 months ago | no reply

Fair enough. Great talk though!

OUR SPONSORS

OUR PARTNERS