I have good understanding of Rust and soon will need to program ESP32 chip. Write a driver and and http/tcp api on it.
Currently I jave seen mixed messages about Rust in embedded. Ecosystem moves fast, but semms like old C/C++ devs stay with their lang. So I'm curious what Rust devs have to say abou it.
The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes.
Compared with C, Rust is absolutely a game changer in terms of reliability/safety/productivity. Every line of C code is a potential liability, because humans make mistakes. Having a compiler that smacks me down is invaluable; it results in a safer and more reliable program, and it helps me get it right the first time. Like many others, my experience with Rust is nearly always "if it compiles, it works". This is _especially_ valuable for embedded programming, because debugging is often way harder when working with hardware.
One major drawback is lack of support/engagement from hardware vendors. They pretty much assume you are using C, and all of their IDEs/SDKs/codegen tools/whatever are written with that assumption. This probably isn't going to change any time soon (ever?). What this means is that if you want to use Rust, you'll be on the hook for figuring out a lot of low-level things like linker scripts, boot sequence, or memory/clock initialization. Often this means reading or reverse-engineering the vendor's SDK to figure out how these work. If you're working at a big company on a serious product, you might have done this anyways. But for a hobbyist, this can be a huge barrier.
My assumption is that with the advent of rust getting into gcc, you will see at least some of these changes starting to make their way into toolchains. Probably not for the MSP430, but possibly for the next generation of embedded chips.
It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers.
Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust.
I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.
embedded software engineering is about understanding the hardware and leveraging its power through good architecture and smart thinking and understanding what the code you write will do. you can’t shortcut this by using a new programming language that does the work for you. you will still need to understand the low level details. so, learn C++ and familiarize yourself with the related embedded standards for reliability and safety.
adding rust into the mix will now require you to maintain code in not one but multiple languages as you cannot get around C or C++ and possibly assembly. it’s already complicated enough as it is, and you should focus on understanding the principles instead of learning another set of syntax and implicit logic.
To me it is very strange that you would act as if Rust is some dumbed down toy language (not your literal words, but I conclude this from your MS frontpage example), while it is considered (not entirely deserved, in my opinion) difficult to learn with a very steep learning curve.
Personally I find programming in C quite annoying because of all the sharp edges (e.g. implicit integer promotion, the various types of UB) that you have to keep in mind. To me this distracts from thinking about good architecture, rather than promoting it.
That's a very cynical take, but I think there's a kernel of truth in there somewhere. Rust does indeed make it much harder for less experienced programmers to make certain classes of mistakes. Why on earth would that be a bad thing?
> you can't shortcut this by...
"Using Rust" and "understanding the hardware"/"good architecture" are not mutually exclusive, and Rust is not a shortcut. Embedded programming is still very hard. In some ways, Rust can make it even more difficult by forcing your code and architecture to follow additional rules.
> cannot get around C or C++
Speaking from experience, this is false. It's perfectly possible to write embedded applications using only Rust and assembly, without a single line of C/C++. I do it every day.
It’ll be a depressing time when the demand for engineering is lower than supply. Until then people with needs larger than resources will find alternatives to “finding competent engineers.”
That said, Espressif seems to be moving past pure embedded and positioning themselves in IoT, for example the latter part of ESP-IDF stands for IoT Dev Framework. This allows them to provide a single way of doing things regardless of implementation within the broad ESP32 family.
Will the results be the equivalent of Frontpage websites? Sure, and as any of those start getting the resources to need and use “competent engineers” they will unlike the efforts that would never have gotten off the ground.
The issue they bring up in more that hardware manufactures will have things like
#define BLINKY_LIGHT_ADDR 0xDEADBEEF
Now, they will almost certainly also define that sort of thing in a datasheet, somewhere, but for the average embedded dev it's far simpler to pull in the SDK and use that.
This isn't some sort of "good programmer bad programmer" filter. This is a "I don't want to read a 40 page pdf of a datasheet to find out what you named light 1 and where that address is"
It's very hard to unlatch your brain from some of the common C/C++ embedded principles of static context variables and thinking of the hardware registers as "owned" memory, which you have to do in Rust. The auto-generated HAL crates aren't that great unless you're using the most common ones like stm32f4 or RP2040. Even then, it's hard to create a portable device driver without delving into generic-hell.
That all said, the ecosystem is moving fast, and a lot of my gripes above are just a product of the embedded rust ecosystem being very new in comparison to C. I do love rtic as a framework, and while I've given embassy a try I think it's trying to do too much aside from being a good async runtime, it should just focus on the runtime and not with stuff like creating its own entire HAL. Hubris and humility are fascinating but I just haven't gotten around to tinkering with them yet.
Lots of good tooling too, and the fact that most of your original C/C++ debugging tools are compatible with rust binaries is just the icing on the cake.
I know that there's the whole Ferrocene project, but until that produces results, stick with C if you're doing safety-critical applications, especially if they need to be certified
I’d much rather have them exposed as some form of atomic that is restricted to operations that are atomic on this specific hardware.
Good HAL crates don't have the entire register set as one struct, thank goodness. And for something like printing a message to serial in a panic handler, there are still unsafe options to yank control of registers, same as C.
What I really like about some of the HAL crates is the usage of builder patterns while configuring a peripheral. Setting up timer parameters before starting it by design is chef’s kiss wonderful.
But if you want to put the whole peripheral set in a static global, you can do that with a RefCell<Mutex<T>> or something similar. Or just yolo it and use unsafe blocks to ditch the mutex.
Yes, it's all trade-offs. You aren't going to avoid all shared responsibility, and will always need micro-coordination. But safe Rust forces you to assign ownership to every structure, at every scale. Some similar effects to opaque data structures, or actors. But unlike those techniques, it allows you to dynamically transfer responsibility.
The most obvious issue is use-after-"free", use-before-"allocate". "Free" and "allocate" don't just refer to malloc--it's any situation where you pinky-swear you aren't going to be touching something.
But more problematic is this kind of code is easy, even natural, to write in C:
- Task A is waiting for a state changes on resources Q1 and Q2. When it sees a particular set, it will modify resource Q3's state.
- Task B is firing off events to Q1 and handling error responses. It might need to stop Q1.
- Since Q1 is no longer changing state, what happens to Q3? Who's responsible for keeping stuff straight? What's "stuff"? Do we need to worry about Q2?
Rust is going to very strongly push you to explicitly designate what owns and is responsible for Q1, Q2, Q3, at all times. "B's got Q1, so A can't even look at it. I'm @#!* going to have to make A tell B what it wants and let B handle it." That was painful, but a good thing.
* Note to self: Write a blog post titled "Atomics won't save you now!" Start a band named "Useless Atomics".
You could also write wrappers, for example one that automatically turns off interrupt when you do a write operation or gives you a guard that lets you write and read the register, which turns off interrupts until the guard is dropped. Or one that has a lock or uses atomics. Plenty of options you can use here.
At that time, I was pushing the cutting edge of what was possible alongside what's now the Embedded WG, but the job didn't work out. I am incredibly interested in finding another embedded Rust role, but have had nothing fall into my lap (my current FAANG handcuffs are quite golden). If you have the opportunity, you should absolutely take it.
C code is a liability, but sometimes liabilities are worth the risk if the payoff is good enough. If you want to move to Rust, you will need to show how the tradeoff changes in Rust's favor. Sometimes that's easy, sometimes that's hard. It depends entirely on your industry and product. For my part, I absolutely believe it is already a competitive differentiator.
* Managing build configurations - I use CMake to build a single application for multiple hardware platforms. This is accomplished almost exclusively through linking, e.g., a single header file "ble-ncp-driver.h" with multiple "ble-ncp-driver.cpp" files for each target platform. I call this the "fat driver" approach which has proven to be easier to work with than creating a UART abstraction or ADC abstraction. Does rust's package system address this?
* Automated device testing - fluid leaks are similar to bugs in software. They are systemic in nature and cannot be easily understood through static analysis. We spent equal time maintaining a test bench as product development.
* Preemptive operating systems - more trouble than they are worth. Often, devs get bogged down writing messages queues to pass items between task contexts and timing analysis requires detailed event tracing.
Given I don't see teams struggle with memory ownership (easy to do if you never, ever malloc), what else can rust bring to embedded dev?
Creating a heap in Rust on a cortex M is safe and cheap-ish with a crate supported by the rust-lang developers. Much easier than implementing your own free() method on a memory pool.
I think you would like rtic. Not a pre-emptive rtos, but a way to manage context between ISR's without relying on some kind of module or global variable that can get corrupted by multiple accessors. Very minimal overhead compared to FreeRTOS
In terms of package management, you can apply rules to what crates you want to include; including specific platform constraints.
[target.'cfg(target_os = "linux")'.dependencies]
nix = "0.5"
https://github.com/tokio-rs/mio/blob/c6b5f13adf67483d927b176...
You can decide how to use them, for example you can very much create "fat drivers".
If you want to see an example, here's how we build for dev vs release, on two different boards. Cargo makes it really smooth. https://github.com/solokeys/solo2/blob/main/runners/lpc55/Ma...
Similarly, for testing, one annoyance for us is that in theory the user should press a button for every action. We have a feature to disable that, just so we can run integration tests (either on PC or on device) more smoothly.
At work I had the same stance as you, and pushed against adding rust to our ecosystem (to avoid fragmenting what was 100% C++/python): - memory ownership bugs are not a problem (and even on the host, with unique_ptr and shared_ptr you can really get quite far) - C++ meta programming is really quite expressive to nip most bugs in the bud (say, writing to the wrong port, adding an i16 to an i32, or adding ms to us), - C++ meta programming is pretty good at building bigger abstraction, such as monadic tasks
Here's the main advantages I see and which convinced me to take it seriously.
- cargo for package management and building. It's extremely easy and "nice" to add packages, manage multiple configurations, build additional tools as part of the building, but run them on the host (say, a protocol parser generator etc...)
This is just huge. I basically almost never reused any code except copy pasting source from other projects or from the vendor lib straight into the project, because anything else was just too brittle, even with CMake. Most embedded projects I worked on had their own idiosyncratic build system based on make, and you had to relearn it every time.
- macros that are actually worth it. THis might be the most exciting thing. I often use patterns such as state machines and other formalisms, but the best I can do in C++ to make them nice to write is mix up some ugly ass macros with some templating, and it always ends up being a mess in the error messages. Rust gives you some really decent "lisp"-y metaprogramming.
- rust works equally well for the bare metal and the highest level scripting. That means that my projects won't end up being a mix of cmake + bash + python + C++, I can do everything in rust.
- the embedded code with an abstracted HAL looks REALLY nice. It's almost arduino-like, except this is actually the real thing. This is what my pairing partner and I came up with to control a SPI display:
fn new(
spim: spim::Spim<SPIM0>,
timer: &'a mut hal::Timer<pac::TIMER0>,
cs: gpio::Pin<gpio::Output<gpio::PushPull>>,
rst: gpio::Pin<gpio::Output<gpio::PushPull>>,
dc: gpio::Pin<gpio::Output<gpio::PushPull>>,
busy: gpio::Pin<gpio::Input<gpio::PullUp>>,
) -> Display<'a> {
return Display {
spim,
timer,
cs,
rst,
dc,
busy,
};
}
fn init(&mut self) {
self.reset();
// BOOSTER SOFT START
self.spi(&[0x06u8, 0x17, 0x17, 0x17]);
// POWER ON
self.spi(&[0x04]);
// CHECK NOT BUSY
self.check_not_busy();
- the community has reached critical mass, and I think it won't be too long until there are actually more rust developers on the market than C++ developers. Plus you kind of get the full-stack experience.
Not an embedded systems developer so an honest question. What do you do instead of malloc? Have a large array on stack and manage memory within that manually?
Then I follow my two rules of embedded development: - no recursion - everything has to be O(1)
If I'm honest, I can't remember a project where I had to use even a pool allocator, which you would usually need if you were trying to do like, reorderable queues / lists / trees or so. I right now can't come up with a proper use case. If you do need to say, compute a variable length sequence of actions based on an incoming packet, then I would structure my code so that:
a) only the current action and the next action get computed (so that there is no pause in between executing them)
b) compute the next action when I switch over (basically with a ping-pong buffer)
c) verify real-time invariants
My most used structure is the ring buffer to smooth out "semi-realtime" stuff, and if the ring buffer overflows, well, the ring buffer overflows and it has to be dealt with. If I could have more memory I would just make the ring buffer bigger.
I'm not sure how clear this explanation is :)
In many systems this isn't a problem. The number of engines, flaps, etc., don't change at run-time :-). If they change, you're on the ground in maintenance mode and can reboot.
Tool chain wise:
ESP32 support is very recent and still based on the C tool chain and this makes it very fragile (you can break your environment easily and it is never clear how to recover except recompiling the entire tooolchain from 0)
Arm is a little better because the support is native.
The community is trying to make a generic embedded Hal platform API and implement it for specific devices. And it is pretty bad: almost no documentation, very few examples, tons of autogenerated code where you need to come back to the C world to understand the actual concepts.
Once you start to get going Rust is a blast to program in and the generated code is pretty efficient.
A small project I shared to help people starting on a raspberry pi clone (lilygo): https://github.com/gbin/rp2040-mandel-pico
> Why not Rust? If you can use Rust, ignore Carbon.
So that's probably one reason.
[1]: https://github.com/carbon-language/carbon-lang/blob/trunk/do...
1. Carbon does not aim to replace C. It targets C++ devs. 2. Carbon is still just an idea. Well, more than an idea, but less than ready. 3. Carbon is meant for people who cannot move to something like Rust. They don't intend to compete in enviroments that have modern options.
I love it so far. There are still some rough edges in the tooling, but overall I'm very happy. The resulting binaries are much larger than C projects, but I'm also opting into a lot of functionality you probably wouldn't always need in smaller environments.
Cargo recently got multi-target builds which is great, and makes this way less of a headache before (usually had to run cargo once per target, now it can do all of them at once).
The next challenge is packaging things up. Cargo gives you a hook for running things prior to the actual crate compilation (e.g. using it plus graphicsmagick to generate a bit font for the boot sequence rasterizer) but lacks the ability to run anything after the build, which means no development disk image building or any image checking can occur without a second command.
There's an open issue tracking this with countless use cases but the cargo team seems reluctant to "replace build systems" (which is ludicrous to me).
STM32s however are a different story... I'm using the stm32h7 microcontroller with Rust in a production product. Its really great.
Hopefully the ESP32 support matures sooner rather than later, which I think would be great for more Rust IoT uptake and Rust embedded as a whole.
I would love to see Rust become the defacto standard in embedded development.
Last year a recruiter contacted me about assisting Volkswagen transition from C++ to Rust for their CARIAD embedded automotive platform.
My experience with Rust is only on application development, not embedded systems, but the job sounded quite interesting and I took a look at Embedded Rust. After discussing it a bit with them, my response to them was to recommend going with someone else, because the way Rust is used in that domain amounts to almost a different language and my experience was not adequate. I said that what they needed was someone that had battled with those arcane details already, not a Rust generalist.
I do think Rust would be good for such systems, but that at the moment it’s weighted down by architecture astronautics.
Rust forced us to structure the code a bit better, that makes it easier for multiple people to collaborate on it. Slightly harder learning curve, but that wasn't an issue in our case.
In the history of solo, we had a couple security bugs that rust would probably have prevented, so this is a plus for the language. Moreover, the cryptography community is pretty active and we can leverage solid + well maintained libraries.
One downside has been collaboration with other OS projects. When we had the C firmware and fido2 library, in less than 1 year we've got 3 other products embedding our code and also a couple manufacturers making demos with it -- a great win. With rust to my knowledge we're not there yet, but of course we're very positive.
Rust-embedded is an easy ecosystem to work with (if immature), and if you want more flexibility, Tock OS [0] is trying to cover that space (also immature, but I'm working on it).
Ability to use STD and their rust creates made it very easy to do.
Tho most of their rust creates are just wrappers around C.
That doesn't mean there aren't companies looking at Rust, because C code is hard to get right. We use a mix of emulators, FPGA simulators, unit testing, static analysis, manual code reviews, and various coding standards to try to avoid introducing a bug. It would be nice to work in a language that took certain classes of memory errors off the table. I'm sure Rust has some monsters lurking in the shadows, but at the level I've tried to adopt it, I haven't found them.
With that out of the way, I like Rust. I think there's good quality basic tooling like IDE support and debugging. but It's a little bit of a crap shoot as to what board support you can get. A lot of times I've been able to get by with "close enough" HAL crates. Chances are you will find a board but may have to write a driver for a particular device. (By driver I mean something that understands how that device works and knows what bits to write at which address to set registers, or I2C commands, or whatever). It's not as bad as it sounds, but you will learn to read spec sheets. Many CPU's are a mix of features supported by the IP the chip manufacturer decides to put into their product. Like they might not support some optional components in that specific chip.
Be careful about ESP32. I believe some are based on the Extensa cores and I think some are based on RISC-V. Those are different architectures. I agree with the people below that recommended STM32 which is a more predictable ecosystem since they're all ARM. M0, M3, M4, etc. are all well understood, highly supported cores. ST's licensing (I believe) requires you get a license for the IP before you can distribute a commercial product based on their architecture. I haven't looked at Espressif's restrictions.