Ask HN: Has any Rust developer moved to embedded device programming?

89 点作者 detuks超过 2 年前

Hi! Was wondering if any Rust developer have moved to embedded land. Did you switch to C/C++ or stayed with Rust? What MCU did you work with? Any tips?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.

18 条评论

reynoldsbd超过 2 年前

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order.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.

评论 #32498617 未加载

评论 #32509705 未加载

评论 #32498135 未加载

quake超过 2 年前

I've done some small embedded Rust applications on various STM32 and RP2040 boards. I've been doing embedded dev in C professionally for 7 years and Rust full-time for 2.5, mix or system and bare metal.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

评论 #32496227 未加载

thenewwazoo超过 2 年前

I had the pleasure of writing embedded Rust in the automotive space for a couple of years about 4 years ago, and it was an absolute game-changer even at that early stage. Being able to write generic drivers that I could easily test outside an embedded context sped development up an incredible amount. Writing the business logic wasn't necessarily any easier with Rust than C, but anything having to do with hardware (and especially concurrency) turned into a if-it-compiles-it's-correct affair.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.

garphunkle超过 2 年前

I've been working in embedded for 5 years and am curious how rust could solve my biggest headaches:* 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?

评论 #32495703 未加载

评论 #32495245 未加载

评论 #32495450 未加载

评论 #32516609 未加载

评论 #32495668 未加载

评论 #32495364 未加载

评论 #32495316 未加载

gbin超过 2 年前

I started to explore the area, mostly arm based (rp2040 and STM) and a little bit of ESP32.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): <a href="https://github.com/gbin/rp2040-mandel-pico" rel="nofollow">https://github.com/gbin/rp2040-mandel-pico</a>

maneesh超过 2 年前

Our company builds a wearable device using an NRF5x chip, and our firmware is written in C. We are moving to Rust for our newest device, in order to run graphical output and RT operations. It is looking pretty sweet!

评论 #32494858 未加载

junon超过 2 年前

Not exactly embedded but I'm writing an operating system kernel in Rust, having done so previously with C.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.

评论 #32494893 未加载

ostenning超过 2 年前

The Rust ESP32 ecosystem isn't as mature as STM32 unfortunately, I would be cautious about beginning a production ESP32 product written in Rust.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.

AlbertoGP超过 2 年前

I took a look and realized that I wasn’t yet ready for it.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.

contingencies超过 2 年前

Not a Rust dev but I like the language. I've learned embedded over the last few years. I used to hate C and avoid it like the plague. On a good day now I kind of enjoy it, in some sick perverse twisted way. I'd say in general the embedded space is more project-centric in general thus new stacks are not at as significant a disadvantage as in backend land at the lower end of the project complexity and regulatory ingress spectrum. You will see gaps in terms of device driver availability and maturity and integration level with silicon vendor toolkits. However, since most projects do not use too much exotic hardware writing one or two I2C or SPI drivers won't take forever, you're probably OK to go Rust. But realistically, for complex stuff, you're going to run in to wall after wall that will eat time and money. If you can meld C/C++ and Rust in one binary or reach godlike device driver implementation status then you'll be relatively free of issues but while I'm sure that's possible once you're at the point where you're writing the whole stack you might be best to look for a job with a silicon vendor overhauling their toolkit for Rust support, since base library and code generation will help shift more product than any one shop. Try writing to TI/NXP/Renesas/STM/Freescale/Microchip/NXP/Atmel's HR department and asking for scope: I'd be surprised if you received zero interest.

ecesena超过 2 年前

We rebuilt solo v2 [1] firmware in rust, compared to v1 in C [2]. I haven't written any rust code so take what I say with a grain of salt, but generally speaking I think our experience has been very positive.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.[1] <a href="https://github.com/solokeys/solo2" rel="nofollow">https://github.com/solokeys/solo2</a>[2] <a href="https://github.com/solokeys/solo1" rel="nofollow">https://github.com/solokeys/solo1</a>

dcz_self超过 2 年前

I'm not a Rust-only developer, but a general systems programmer, and my foray into embedded is limited to a side project (see my profile), but no, I haven't switched to C/C++. Rust brings too much goodness to give it up.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).[0] <a href="https://www.tockos.org/" rel="nofollow">https://www.tockos.org/</a>

adolph超过 2 年前

I’ve been super curious about both Rust and ESP. It seems like Espressif is interested enough to commission a Rust dev board (ESP32-C3-DevKit-RUST-1) and training using it.<a href="https://github.com/esp-rs/esp-rust-board/" rel="nofollow">https://github.com/esp-rs/esp-rust-board/</a><a href="https://github.com/ferrous-systems/espressif-trainings" rel="nofollow">https://github.com/ferrous-systems/espressif-trainings</a>

评论 #32496162 未加载

phoehne超过 2 年前

I recently moved to an embedded software role. I sought out this move because I love writing code for very small computers, fiddling with registers, Blinky lights, etc. I didn't realize how important an accredited RTOS was for many commercial projects. It's not really about middle-aged devs being stuck on grungy-old tech. It's about being able to support a device for the next 10, 20, or 30 years with a consistent tool chain. This is especially true for devices that have some sort of industry accreditation, like medical devices. It's very expensive to get that accreditation and if you change the embedded language, that will probably start the process all over again.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.

_whiteCaps_超过 2 年前

Oxide has an embedded Rust RTOS:<a href="https://hubris.oxide.computer/" rel="nofollow">https://hubris.oxide.computer/</a>

LaffertyDev超过 2 年前

I'm a rough beginner in the embedded space. Would love to use Rust, but in my experience it becomes more hassle than its worth for some of the more off-the-shelf controllers. Would love to find more knowledge / tutorials to help guide me in the right direction, though.

jmartin2683超过 2 年前

I write Rust full-time for work and use it on embedded projects for fun. The ecosystem around embedded-hal is great.

nottorp超过 2 年前

Being dependent on any programming language is a trap. For your esp you need intimate knowlegde of the hardware and the language is irellevant.