by detuks on 8/17/22, 10:58 AM with 61 comments
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.
by reynoldsbd on 8/17/22, 2:28 PM
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.
by quake on 8/17/22, 12:46 PM
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
by thenewwazoo on 8/17/22, 3:53 PM
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.
by garphunkle on 8/17/22, 12:06 PM
* 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?
by gbin on 8/17/22, 12:12 PM
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
by maneesh on 8/17/22, 11:20 AM
by junon on 8/17/22, 11:31 AM
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.
by ostenning on 8/17/22, 12:35 PM
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.
by AlbertoGP on 8/17/22, 1:11 PM
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.
by contingencies on 8/17/22, 11:39 AM
by ecesena on 8/19/22, 12:45 AM
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.
by dcz_self on 8/17/22, 12:33 PM
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).
by adolph on 8/17/22, 1:03 PM
by phoehne on 8/17/22, 2:54 PM
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.
by _whiteCaps_ on 8/17/22, 3:12 PM
by LaffertyDev on 8/17/22, 7:01 PM
by jmartin2683 on 8/17/22, 8:52 PM
by nottorp on 8/17/22, 6:02 PM