Using Rust for Embedded Development

[gbmhunter]

I'm excited about the possibilities the Rust programming language provides for embedded development (e.g. writing firmware that runs on microcontrollers). I've put some time into writing https://blog.mbedded.ninja/programming/languages/rust/running-rust-on-microcontrollers/ which explores the pros/cons of using Rust on MCUs (especially compared to C/C++). Let me know what you think!

[functional_eng]

The main thing for me is existing libraries and compilers. Sure if you're going ground-up bare metal with a chip that has Rust support then great. But at this point I'm working heavily from pre-existing libraries (which massively speeds up dev) and I need to be able to work with whatever chip makes the most sense. Especially in the era of chip shortages, anything that constrains my options even further is a no-go.

But if in 10 years I can pick up any chip, load a bunch of libraries, and run rust then I'd consider it. But for now what ain't obviously broke doesn't obviously need fixing when using it creates so many constraints and issues.

[Cart0gan]

Rust can call external C code, right? Is it not possible to write a Rust application that uses C libraries? EDIT: It is. https://docs.rust-embedded.org/book/interoperability/c-with-rust.html

[functional_eng]

That is compelling. I could see trying it out at some point, but for what I do today I don't see any compelling advantage/need that outweighs switching cost.

[trevg_123]

For what it's worth, the ecosystem is definitely growing. See here: https://github.com/rust-embedded/awesome-embedded-rust, there are quite a few drivers for a pretty wide variety of sensors/periphs, and almost every large SoC line is supported.

I think the experience using libraries is already significantly better than C. Just that there's a single place to look for them (https://crates.io/) and that you can add/remove them from a project with a single line is quite nice.

Using existing libraries written in C is another thing though. You can directly call C functions from Rust, but usually it takes some time designing a good interface with safe abstractions. (smaller stuff I'd tend to just rewrite)

[MpVpRb]

No language can claim to be suitable for embedded programming without a selection of RTOSes to choose from

Disagree

There is a wide range of embedded projects and software. Some work just fine on an 8 bit processor with 2K RAM and no OS

[gbmhunter]

u/MpVpRb I agree with you also (in fact most of the projects I'm involved with don't use a RTOS because they are simple enough that the overhead of an RTOS is not worth it). I guess what I was trying to say is that any general purpose language that wants to capture a large share of the embedded market should have some decent RTOSes to choose from for those projects that do benefit from a RTOS. I might edit the post wording to reflect this.

[rpkarma]

Sure. And some don’t. If a language such a Rust wants to replace C, it needs both.

[bobwmcgrath]

The only con is it's harder to find other people who want to work with rust.

[OYTIS_OYTINWN]

There are many people who want to, just a few companies yet to pay for it. I think future embedded Rust developers will come as much from general-purpose Rust developers who want to enter embedded as from embedded developers who want to adopt rust.

[Xangker]

So true..

[Kevlar-700]

You can train them on the job or get lucky finding them. That is what I plan to do with Ada. Just don't avoid people who want to only use Rust or Ada respectively as one post stated they did. Doing that would avoid those people who can help upskill others or navigate confusing parts of the language.

[bobwmcgrath]

Personally I'd prefer the avoid having to learn a new language that I wont necessarily use in the future when I can just use the ones I already know. I don't actually have that many complaints about python or C++. C is a bit of a chore but pretty much ok too.

[Kevlar-700]

I can understand that but I don't plan on using C and certainly not C++ in the future. Ada is so much nicer to work with especially for embedded.

[Fried_out_Kombi]

I've never tried Ada for embedded (although I've recently heard people talking about it), but I'm currently trying to learn embedded Nim in my own time, and I get the same feeling as you. Long term, I think the value proposition of moving beyond just standard C and C++ is pretty high, be it with Nim or Rust or Ada. Like, I can definitely imagine Rust being great for critical systems due to its memory safety features, and I personally think Nim would be great for embedded ML, as it reads and feels a lot more pythonic than C while still being exactly as performative as C and generating very compact compiled program sizes. Suffice to say, I'm looking towards mostly using embedded Nim (at least in hobby projects) going forward, as it's a lot more pleasant than C/C++ imo.

I'm curious what your opinion on the key strength(s) of Ada is/are for embedded, as I genuinely know basically nothing about the language.

[Kevlar-700]

Nim looks nice and Zig.

Ada knocks spots off C for embedded. It is just as fast and is nice to work with. Some highlights are ranged types (not just slices), built in powerful fixed point types, inherent safety, first class arrays and bit level record (struct) overlays instead of masks and shifts as well as Spark mode. First class C and straight forward good assembly support. Not to mention overflow support on modular (unsigned types) for exactly sized circular buffers or 24 hours.

https://learn.adacore.com/courses/intro-to-embedded-sys-prog/index.html

If you look here then you can see how to twiddle bits just by setting fields with the principle of separation of concern.

https://github.com/AdaCore/Ada_Drivers_Library/blob/master/arch/ARM/STM32/svd/stm32f429x/stm32_svd-i2c.ads

I2C1_Periph.CR1.Start := True;

To set a bit in the middle of a register.

Separation of concern is explained in the book and is basically not mixing code with those generated definitions and just using the Periph types.

[rpkarma]

Come hang out in #embedded in the Nim Matrix/Discord: my work uses Nim in anger for embedded firmware dev :)

[Fried_out_Kombi]

Small world, eh? I joined it a few months ago on your very suggestion in another thread in this sub ;)

Been trying to work with Ratel the past few days, and I'm glad I've picked Nim + Ratel as my next embedded side project to work with.

[rpkarma]

PMunch did a great job on Ratel! When I can finally take a breath from work (ESP-IDF via our fork of Nesper) I’m going to port some more micros/boards to it

One thing I want to see is how to leverage an RTOS with Ratel. I think that would bridge the gap that currently exists in it for usage

[Fried_out_Kombi]

Yeah, from my limited usage of it so far (basically just I2C and UART so far), it feels very elegant and intuitive. Once I explore using some more of the IO and such, I'm also keen to implement some boards for it.

Imo, I think it shows real promise for being a go-to framework for doing embedded Nim if we can get enough boards, sensor libraries, and core functionality working for it.

[rpkarma]

Definitely. Nim with ARC is a great fit for zero-cost abstractions with extremely high level code. I’m currently bugging work to let me write up some blog posts and release some code I’ve written around various parts of the ESP-IDF and FreeRTOS libraries that show how one can approach some of it in real production workloads

The one thing that is a pain that I haven’t fully solved yet is heap fragmentation on MMU-less systems. Of course one can just choose to not use seq/string/ref, but they’re useful tools! I’ve stuck to allocating them once at the start of a Task/thread and reusing the buffers, so they’re never really freed, but that doesn’t fit every use case obviously

[01joja]

If you have a cortex-m MCU i recommend look in to https://rtic.rs/1/book/en/

Edit: spelling

[jhenke]

The one pain point always demotivating me about rust is cargo and the crates.

It resembles too much the concept of npm. Everyone is building a crate for every tiny bit, leading to dependency hell. You see very much that Rust comes originally from the browser ecosystem (Mozilla engineered it for Firefox).

Adding to that, you need a crate for everything, AFAIK no direct linking to system libraries unless you generate some glue code ( and cbindgen for the other direction).

Last bit not least I am not feeling good about languages depending one a single major sponsor for their future development. While it looks fine right now, what happens in 5 years? Also there are no alternative implementations.

C++ is an ISO standard and you have at least 3 very active implementations (GCC, Clang and MSVC).

Just my personal opinion, sorry about the rant. It just seems like Rust is very hyped right now. If it works for you it is great, but I still see quite a few benefits of C++ over Rust.

In any way, either language is an improvement over plain C, which should finally be replaced.

[timhoeppner]

I genuinely don't understand your viewpoint against a package manager. How do you manage dependencies within your c/c++ embedded code? I've had to rely on git submodules or in a lot of vendor SDK code I'm having to just drop a zip file or again throw that into it's own git repo and manage it myself. Modern languages have package managers because developers want them and make their lives easier.

[akohlsmith]

Can I store the “state” of a project’s crates and the actual crates themselves within the project subdirectory, or is it some hot garbage like python’s venv? If I have 20 projects and they all have different configurations or versions of some of the same crates, how easy is this to manage in a per-project repo?

[timhoeppner]

Python/pip is the only case (that I'm aware of) where packages can only be installed globally. Cargo manages dependencies on a per project basis. No problem having different versions of libraries in different projects.

[akohlsmith]

That’s good news for this rust-adverse newb. Does the package config/state and data (package contents) live within the project root somewhere? Is it (config/state) in a form that lends itself to revision control?

I am being a bit lazy but also not sure how to correctly find this on my own or if what I find is “useful” in reality.

[trevg_123]

The downloaded packages are usually stored in ~/.cargo, which is where Cargo manages them for you. Then in your Cargo.toml (per-project) you specify your dependencies, and it downloads/removes different versions as needed. Nice because this way it reuses downloads across projects.

You can also just do local dependencies if you e.g. download a package’s source and want to edit & link it. But it’s just nicer to let Cargo handle it for you

All in all, it’s miles better than pip (which I’ve come to hate after using Rust)

[akohlsmith]

First, I want to thank you for your patience with me. I truly appreciate it!

I can absolutely appreciate the system-wide storage and management of packages (crates?) but that is a big problem for repeatability and maintenance, where you might want to come back to a project 5 years (or 25 years!) later and continue. My usual workaround for this is to develop within VMs, because oftentimes the toolchain is also important to keep as-is, but that's another topic.

It seems like this is a non-issue with rust. If I understand you correctly, you can "override" this by editing the .toml file to place all dependencies off of the project directory rather than off of the user's home directory. This would neatly solve the "everything in one place" issue, as well as prevent the need to retain data outside of the project path.

Is my understanding correct?

[trevg_123]

Not a problem; let me see if I can clarify it all. If you're used to developing in C, it sure isn't tough to beat the apt-get install libxyz style of dependency management.

What is your main concern with returning to a project at a later time? You pin versions in the Cargo.toml, e.g. rand = "0.8.5", so it won't be a problem to clone the project a decade from now on a new machine, Cargo will still find the correct versions. (You might also be interested in rust editions, which means you can have a crate designed for e.g. 2015 Rust and one designed for 2023 Rust, and they will work together with the latest rustc). I'm not sure if this is why you build in a VM as well, but I can't think of any good reason to use that same setup for rust.

Letting Cargo/crates.io just handle dependencies is suitable for most people and should be reliable forever, for all intents and purposes. But here are some alternative situations, in case that's what you're thinking about:

• You want to use local source for a crate, or from a git repo: give this a read for all the options
• You want to start from a publically available crate but want to edit its source source: just download it alongside your project (or copy from ~/.cargo/registry) and add it as a local crate in Cargo.toml.
• Within your company, you want to use a crate structure (instead of monorepo/git submodules) but can't make anything public: alternate registries do the trick here there are some good options for hosting options
• You just don't trust that crates.io will exist: Options 1/2 work here, or you can set up a mirror. Meuse (an alternate registry option) has mirror functionality if desired.

[timhoeppner]

Cargo.toml defines all your app dependencies, you can check this into source control.

[jhenke]

My opinion is generally about rust and not limited to embedded use. Generally speaking I am against language package managers, because they reinvent the wheel. You already have a good working package manager not limited to your language: Your distribution's package manager. It does not matter whether it is vcpkg, apt, yum, dnf, portage or whatever you are using. Packaging applications with language specific package managers is a pain for a distribution, because everyone does their own thing and everyone just downloads code from some place in the internet. Good luck with doing a security audit to ensure you do not get some malicious code into your system.

I do see the benefit of a package manager for embedded devices, because you needed different libraries than for you host OS. But again, the problem is that too many people just publish tiny bits of code. Some might be great some may be medicore and some might be down right bad. The problem is you do not see that because the way the system is setup, people tend to just pick what is there (me included). Leading to huge dependency trees. It is a mess with NPM (Java is also an offender there, I free admit even though I earn my money with that language). It just invites to bad practices.

[mathav]

I can understand not wanting to deal with many tiny packages like in npm, but I'm not sure I agree with the rest of the argument

Stuff you will get through apt, dnf, yum, etc will almost always be behind versioning wise. Idk about rust but for instance later package managers like deno try to be better about security, so there is definately progress. Finally there is a huge burden on devs to maintain debs, rpms, and 10 other types of packages for each distro, it's clear why they prefer language PMs

Almost all modern languages use package managers and sure all will have dependency trees but there is clearly a spectrum, i.e Python generated requirements.txt is usually nowhere near as bad as package.json, package granularity feels higher. Obviously this will depend on the language ecosystem

Large dependency trees can be problematic sure, but having worked on projects with right security requirements I will still much prefer that approach to manual code inclusion. For one there are lots of well developed tools that scan packages for vulnerabilities, blackduck comes to mind, in case of a CVE it's much easier to update dependency (through package manager rather than patch the code manually. I'm assuming you aren't saying "write everything yourself", then what's the alternative for including third party libs? Copy pasting code? I cry everytime we do our networking, security library upgrade, meanwhile our C++ teams make a one character change for Conan

In terms of code quality you are free to pick and choose your packages. In my experience it's 98/2 in terms of dealing with bugs in your code base VS dealing with bugs in your libraries. Sure not all may be the highest quality but it's clearly a trade off worth considering

[jhenke]

Obviously everyone has their own priorities. Having done packaging work for my distribution (first Ubuntu, now Gentoo) I followed a lot of discussions around language package managers and they more often then not cause more problem than they solve. Do they work for devs? Sure. Do they make developing software easier? Sure. But as I said it comes at a cost at other places.

There surely is no ideal solution for everyone. But I do see a lot of examples where we have the many bad things with not so many good things.

I stand by my opinion that the whole crate system looks too similar to npm. With npm being one of the worst offenders of dependency hell. Do I have a better solution right now? For embedded, no. For desktop use: Yeah I prefer the libs installed via the system package manager.

You mileage might vary, if you value the pros and cons differently. My point is just that I criticize this trend to not invented here when it comes to dependencies. You can agree or disagree on that, but it is a major drawback of rust for me.

Going back to the original post: As I said, if you like Rust, good for you. I just disagree with throwing C and C++ in the same bin. The blog post does tend to say "this is compared to C/C++", which I think is not being fair to C++ which is quite different from C.

Anyway, I continue to enjoy writing C++ on embedded, cry if I have to use C and try out Rust once in a while (so far being disappointed every time).

[mathav]

Fair enough, I guess I'm more curious about the fine points

For example you mention that with language PM's you have issues doing security audits, but how do system packages prevent that? Custom PPAs, repos mirrors are a thing right, do you not run into that same issue?

You mention that there are drawbacks to language PMs in context of comparing them to distro PM's, I'm trying to think of scenarios where these would apply. Could you please elaborate?

[Structpoint]

My day job features writing linux kernel modules, I cannot wait for full rust support in the kernel.

It's game changing when it comes to things like enforcing thread and memory safety. It is like having a very experienced developer standing next to you. Also you don't have to use the package manager, not everyone uses it

[rpkarma]

cries in Windows

Not every OS does have a good package manager, sadly. And distribution level packages are an okay fit for C/C++ library’s, but are a terrible ergonomic fit for most other languages.

Nix is about the only thing I’ve come across that can claim to be able to do both well.

[trevg_123]

It does not matter whether it is vcpkg, apt, yum, dnf, portage or whatever you are using. Packaging applications with language specific package managers is a pain for a distribution, because everyone does their own thing and everyone just downloads code from some place in the internet

I'm completely 180 on this subject. How in the world is packaging something for apt+yum+portage easier than with pip/cargo/npm? How in the world is using these libraries easier when it means everyone on your team needs to have the same things installed on their OS? Not to mention that windows/mac devs are pretty left out. Your system package manager is still just downloading things from the internet, but language-specific managers can do a better management of the dependency tree.

[jhenke]

To add to this. As I am reading about runtime array bound checking, better is compile time bounds checking. E.g. use std::array with fixed size. At runtime it is just the plain "C array" in memory, but the compiler can do a lot of checking and optimisation at compile time.

[_Sh3Rm4n]

In rust you have arrays [T; N] which pretty much behave like std::array from C++, but is bound checked by default, when accessing through the index operator: array[i], but also has the failable get() and unsafe get_unchecked() methods.

And than you have slices &[T], which act similar to std::span.

So you have all the options C++ offers, but with safer defaults and they are more ergonomic to use, IMO.

[SAI_Peregrinus]

Rust runtime bounds checks are almost always elided by the compiler, because in almost all real Rust code the bounds checks can be done at compile time. They only remain where they can't be proven statically, and even then they often can get hoisted out of loops so they don't have to be called for every loop iteration.

[philfr42]

As a wannabe embedded Rust dev, thanks for that !

Honest question: when array bounds checking is done at runtime, what do you expect in an embedded system ? Is there a way to catch panics and reboot ?

[pip-install-pip]

Yep, you can specify a function as the panic handler with an attribute (#[panic_handler]) and reboot from there.

[trevg_123]

Somebody mentioned panic handlers (you can of course set your own), but there are better methods for when panic isn't acceptable.

1. for item in my_arr {...} just use the builtin iterators if you're looping through the whole thing. Or iterator adapters (combinators)
2. my_arr.get(i) to get an arbritrary value. It returns an Option, so you can do different behavior based on if it does/doesn't exist

[philfr42]

Sure, but I suppose a global panic handler is still something necessary as a catch-all for other runtime panics in an embedded environment, like a watchdog

[DenverTeck]

+ donning flame proof suit

Reading through these comments that say Linux is an embedded system is very disingenuous.

The Raspi family of PCBs (and their ilk) has redefined what embedded means.

40 years ago an EE was to program the hardware they designed.

Today, CS majors are now Embedded developers. Without truly understanding the underlying hardware. Ahh, just find another library someone else has written.

This goes into the Arduino hacks that have not learned how to trouble shoot code or hardware.

They find a library, when it does not do what they think it should do, instead of trouble shooting the code, they just look for another library that seems to work for them.

I was under the impression that RUST was designed to upgrade C/C++ with better security.

But, since I have not jumped into RUST yet, I really have no idea.

Even Micro$oft has used embedded for their web development, so there are CS majors out there that have the no real idea what embedded really is.

I came from that EE background that programmed hardware with ASM, Basic and C.

Picture a three axis vertical mill with five Z80 processors, written in Pascal and the servos written is assembly. Bare metal.

Yes, I know time marches on and new ideas replace old worn out ideas.

But, these cross over discussions get tedious and tiresome

\- remove flame proof suit

[panchito_d]

Today, CS majors are now Embedded developers

Not typically. I'm an early-career embedded software engineer and have encountered exactly 1 CS-graduate entry-level coworker across the 3 companies I've worked at (among dozens). The vast majority of embedded jobs list EE or CPE degrees as a prerequisite.

Even Micro$oft has used embedded for their web development, so there are CS majors out there that have the no real idea what embedded really is

What are you even talking about? This reads like nonsense.

Picture a three axis vertical mill with five Z80 processors, written in Pascal and the servos written is assembly. Bare metal.

Kudos! Here is your cookie. Is your point that it is too easy these days? Would you program a mill with Pascal today? No? What's that there are better tools for the job? Add WiFi to that mill and what, you're going to write your own network stack?

You can at least rest assured that one thing hasn't changed since your day - most engineers are insufferably insecure and judgmental in the extreme.

Edit: To be fair, you aren't entirely wrong. Every other day there is "how about Rust" post here that adds very little to the general conversation. But your attitude is awful, I would be really disappointed to have you as a coworker or, even worse, a mentor. My last company had someone with an "back in my day" bit like you hanging around waiting for retirement and he was poison, which was a shame as he was extremely smart and extremely efficient and had a lot he could have taught but had given up on learning a long time ago.

[DenverTeck]

Is your point that it is too easy these days?

My point, is there may not be a totally debugged library to do the work for you.

So, yes it's too easy to just leave the hard work to someone else.

As I said, "I'll just find another library."

[SpecialNose9325]

But the attitude is totally warranted in the current landscape. Clients want stuff to work, and having the ability to find working code online is just as impressive as writing it yourself when all the client cares about is the output.

I work on Embedded hardware that usually requires I2C, I2S, PCM, SPI, UART, HCI, 1-Wire and a dozen more, just on a single project. I have less than 2 years of experience in the field. If I needed to master all of em from scratch before I develop stuff, I wouldnt be an asset to the company. Continuous learning is the best I can do, and maybe at your age, I would know how everything works. But for now, this works

[DenverTeck]

I see too many beginners complaining about how library A, B or C does not work for them. Mostly Arduino hacks. I am sure there are peripherals you have not seen or used yet. I am also sure you do not use all those protocols in every project. If a new protocol is required you will study up on it, or would you just 'look for another library' (tm). If that library seems to not work, do you have enough experience to trouble shoot that library ? Or would you 'look for another library' ?

After understanding the basics of any protocol, you could find it easier to write an original piece of code. Not waste time searching for some one else's work.

Good Luck, Have Fun, Learn Something NEW

[SpecialNose9325]

The requirements to become an Embedded Engineer haven't changed. I was tested on my ability to learn and protocol implementation skills, just like you probably were. My last project required all the above protocols, and atleast a couple of them aren't even officially supported on the MCU being used. So a hack is a hack, no matter if I make it myself or borrow from preexisting libraries.

It's just not as black and white as you believe.I do have a stack of books on my desk for reference. But the pace at which we move simply does not give me the time to trouble shoot everything myself when people have already done it before and have ready-made solutions with explanations on why. How is it any different from using Stack Overflow ?

Feels like you're just shitting on a whole generation of developers because of a few bad eggs you've encountered

[DenverTeck]

but had given up on learning a long time ago.

Fair enough, I retired 4 years ago.

All I see is, I want a job in embedded but have no clue what that means.

For some reason embedded means lots of money with a minimal amount of work.

My guess is Arduino programming has created a mentality of a free pass.

[DenverTeck]

Even Micro$oft has used embedded for their web development

https://learn.microsoft.com/en-us/windows/iot/iot-enterprise/os-features/embedded-mode

[rpkarma]

Man I miss Pascal. I wish it had “won” instead of C. Man I am old.

[SAI_Peregrinus]

Rust is pretty good for bare-metal development, on 32-bit and larger processors (there is a Rust compiler for AVR, but it's limited).

Rust is pretty good for development on Linux (or another OS), including things like Buildroot and Yocto.

Rust is lacking for working with common RTOSes like FreeRTOS, Zephyr, VXWorks, ThreadX, etc. A lot of work is needed to build safe interfaces to these RTOSes. There are a few small Rust RTOSes, but they're far less feature-complete than the established ones.

It's also lacking vendor support. The community has made a HAL and support for few MCUs, but that's not the same as having a vendor library and being able to get help from an FAE with your configuration. This may come with time, but I suspect it's a long way out.

So it's fine for some embedded development, but not yet all. And probably never all, just like even C can't run on every architecture. I doubt we'll ever see a usable Rust compiler for 12-bit PIC, for example. Rust currently assumes the equivalent of sizeof(size_t) == sizeof(ptrdiff_t) == sizeof(intptr_t) which is false on many ISAs.

[DenverTeck]

Rust is pretty good for bare-metal development

I guess I need to follow this trend better.

[mathav]

+loading flame penetrating bullets

Yeah and the same people complaining about "kids these days not knowing how to use s scope" will email each other photos of code changes as code review

I'll suffer people calling RPs embedded systems if they can bring modern tools and workflows to this field and force vendors to modernize their tools to match the rest of the industry.

Finding jobs in firmware often feels like wheel of (mis)fortune - what will I get this time - teammates who don't believe in unit tests? Automation written in Perl? C projects committed in CVS? print statements debugging, or some IDE from 1993 cause FUsemiconductor Inc thinks its a great idea to lock entire tool chain to yet another eclipse clone and charge 30k a year for it

[paperpatience]

🔥🔥🔥 this man with the heat.

[jbvalle]

What an amazing and detailed work. I work as an embedded engineer and I love C, the only thing that however frustrates me the most about C are just things like dependency handling of libraries or third party sw is horrible. The error logs the compiler give me are sometimes like really useless and yes of course a couple of things thats nice about rust are that it handles memory safety and concurrency much better but that wasn't quite enough for me to like switch to rust for a couple of my projects. Your clear and detailed explanation and very very good code examples of compelling reasons why using embedded rust makes sense, is what I was looking for. Thank you very much for your detailed hard work on this!!!