Hacker News new | past | comments | ask | show | jobs | submit login
Rust on Espressif chips (mabez.dev)
230 points by lukastyrychtr 36 days ago | hide | past | favorite | 69 comments

I was looking forward to trying Rust on my ESP32 projects but always had a hard time. All the tooling is too complicated. There is flasher coded in python, IDF coded in C, you need to run MinWin on Windows which makes it even harder. You can't run all of this in docker because docker for windows doesn't allow mapping COM ports into container and stuff.

Everything about just compiling a code seems so tiresome and unstable in comparison with STM or Atmel environment. Yet still I love ESP32 even though I gave up trying to code it in Rust. Even C++ was not working well and had to make several pull requests to add `extern "C"`s into IDF codebase for my code to work.

I'm looking forward to improvements on the Rust environment.

Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack?

Well not to be inflammatory, but aren't you making your life more difficult by doing development on Windows? You could just run Windows in a VM if you need any Windows specific software, and have your main OS be something more suitable for software development.

Of course ideally everything would just work on Windows, and there's nothing wrong with running Windows as your main os, but the reality is that especially bleeding edge software development tools will never be as good on Windows as they are on Linux or MacOS, just because bleeding edge open source software developers generally do not use Windows.

It's just a personal reason. I make my living on linux and my personal computer is windows os. I like to turn off my work computer as a symbolic gesture and do my hobbies on personal computer. Just to divide work and personal headspace.

I play a lot of games and use lab software for electronic engineering so Windows is a must.

And try to convince my wife I need a third computer.

In my experience Windows is the generally the best supported for general embedded work, video, graphics, audio, hobbyist, IDEs, etc. Linux has the best for server and server related hardware but is often pretty equal..ish?

MacOS...has a monopoly on developing for Apple products, but I can't imagine the embedded toolchain is particularly good?

I do enjoy the image in my head of some hipster guy in a coffee shop with a macbook, scope, power supply and a bunch of wires sticking out a pcb trying to debug something though.

It's the best supported for "official developement" with "official toolchains", but Rust is very much not that. If you're going to do non-official programming of the devices with a language that is not the officially supported language, don't use the OS that doesn't have any of the community supported tools.

I'm not sure of the situation with ESP but in many embedded environments you HAVE TO use Windows for development.

I do ESP and ARM (NRF52) dev on Linux with no issues. I haven't had a chance to try the Paduak tools under Wine yet.

esp32-rs works fine on linux

I think more embedded devlopers should insist on only using linux tooling. Windows is a broken platform for software development. Programming an embedded device should be as simple as using GCC and a flashing tool.

Requiring some kind of insane windows IDE seems like such a 1990 way to develop software, imo.

That's only true if you're using the officially supported toolchain. Rust is not that, so there's no point in using Windows.

Not the situation for ESP, but the C++ pain is real. Once that is sorted, it works great on mac.

I've found the Rust embedded tooling is equivalent on Windows and Linux. Ie the same tools and programs work, and in (almost) the same way. More broadly, Windows is more popular for embedded. My anecdote here is limited to Cortex-M.

>bleeding edge software development tools will never be as good on Windows as they are on Linux or MacOS

Personally, I've never experienced any better IDE than Visual Studio. I would call it bleeding edge.

In general, Rust development on Windows, including at least the embedded platforms I work with (ARM), is identical to Linux or Mac.

As sibling says, for embedded toolchains Windows is often the best supported platform.

Nothing like proprietary tooling to really make everything 1000% more painful

I did not liked the old ESP flasher tool much either.

FYI: There's already an official rust based rewrite of it: https://github.com/esp-rs/espflash

If you're up for it there's a lot of fiddly work you can do to make your windows serial device exposed with a RFC2217 network server and then mapped as a serial device inside your container. Can see the basic idea here: https://gist.github.com/DraTeots/e0c669608466470baa6c You'd want to use hub4com to go serial device -> network server on windows and then socat or ser2net inside the container to go network server -> serial device. I agree though it is entirely too complicated and much more of a pain than it should be in practice.

I had an easy time getting setup with the esp32c3 with this repository (linked to in author's first post): https://github.com/ivmarkov/rust-esp32-std-demo

Also got it working on WSL2. I could install flashing and monitoring tools as Windows binaries, which have access to Windows ports. https://pfesenmeier.github.io/wsl2-and-embedded-development/

That's because the c3 is a RISC-V chip and so doesn't require all of the annoying tooling that parent comment is referring to.

The rest of Espressif's product line, including the extremely popular original ESP32 and the older 8266, use different chip architecture (xtensa) that requires a more annoying setup.

It was easy because of ivmarkov's tooling (see linked repo in previous comment). The "flasher coded in python, IDF coded in C" is installable through cargo. I did not have to install "MinWin". Docker does not having access to ports, but WSL2 does have access to the computers ports (through cross-compiling build tools).

Not having to install custom Rust toolchain for Xtensa chips was nice, too.

I stand corrected, that's a useful template project. Thanks for linking!

> Wouldn't abandoning Xtensa architecture for RISC-V help? Are there any plans to simplify the stack?

I mean, the new one's are already risc-v based and they added tier-3 compiler support for those in rust recently (1.56 IIRC), not sure if they still plan to release xtensa based ones in the future.

Yes but they didn't yet release dual-core RISC-V based or did I miss it?

I use it's dual-core capabilities extensively as I heavily utilize WiFi and still have to maintain low-latency processing of IO input.

Didn't look much into RISC-V ESP but does it have some interrupts without multiplexor?

Yes, esp32-c3 [0] can be bought already, e.g., from mouser [1] or sparkfun [2] either as dev kit or as native module for a self-designed PCB.

[0]: https://www.espressif.com/en/products/socs/esp32-c3

[1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02...

[2]: https://www.sparkfun.com/products/18034

They asked for dual core. The C3 is single core.

> ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz


And ESP's rust support provides threads and async supprot nonetheless.

With a zero-cost async implementation you may not require multiple cores, for some hard realtime stuff maybe, but even that can be handled by the work scheduler.

The challenge in single-core timing-important ESP development is using the wireless peripherals effectively while maintaining I/O scheduling. Even with "zero-cost async" at the application layer, the WiFi and Bluetooth implementations are mostly software and will be getting scheduled on that same single CPU. You don't really get to control their scheduling in a granular manner, so meeting timing is pretty hard in many situations.

This is probably the most annoying thing about ESP development, but mostly goes away when you can just dedicate a core to the "ESP stuff" and then run your application on the other core.

They are mostly software but the actual time critical RF stack isn't, those esp's have that in HW (at least their manual suggests that) and the remainig Bluetooth or wifi stuff does not need to run in an interrupt disabled critical section, so can work fine with an time critical app, but naturally depends on how much transmissions need to happen and how time critical and compute intensive the application is.

"low-latency processing of IO input" may well be talking about hard realtime stuff, for which threads/async on a single core doesn't help you.

They do help, hard realtime only means that there can be no blocking (critical) section with a possible unbound time limit, toggling an IO register with a lower frequency as the CPu clock can still be done while shovelling in datagrams into the RF stack that can DMA acces in withput any CPu doings anyway..

i agree it can be done but it's a fragile balancing act. What I don't agree with is that Rust provides anything particularly special allowing you to do this.

> but it's a fragile balancing act.

It only is if its done that way.. Normally you use a small RTOS that provides some sane abstractions to handle such mix of tasks or you can add some code that does that, for simpler applications (where simple does not mean uncritical or not hard RT) that can work fine too, and especially a single core can make things easier to argue about.

> What I don't agree with is that Rust provides anything particularly special allowing you to do this.

Well, compared to what? While there are already some languages (like nesC) or "frameworks" (OS) that do something like that they are well, frameworks and not a language or tied to a specific "runtime (environment)" like nesC is to tinyOS.

Rust itself provides protection against data races, which already helps a lot for making it less fragile, as you call it, and it also provides type-based (thus zero runtime cost) access control and design contract functionality, check:


Compared to plain C, ASM or C++ this is something special that rust provides in helping to do that.

Look, I do not argue that two cores do not help to have to separate domains for different level of critical, but quite often you do not require that, I mean I did some hard RT applications with FFT + a PID controller running or some fixed point physic calculations going on plus an user interface + GLCD output and communications (e.g., wifi, zigbee and/or UART) on a very basic 16 MHZ or sometimes (for bigger stuff) 32 MHz AVR chip.

Compared to that AVR chip, which could already handle a lot of not-so-simple hard RT apps here, the ESP C3 RISC-V CPU has:

* 160 MHz – so 5 to 10 times more, and a 4-stage pipeline compared to 3 on the AVR IIRC

* 15 levels of interrupt priority one can configure (the AVR only had a fixed level and the ISR basically had to turn of interrupts completely.

* a general DMA engine that can handle 108 to 128 MB/s so way less work for the CPU to shovel data towards UART, I2C, SPI, the crypto engines or the WiFi Bluetooth stacks.

With all that you got most of the more frequent interrupts stuff gone even while sending lots of stuff over the ether and the CPU can handle the actual app.

It takes at most an hour to setup the tooling on windows. My first intro into embedded development was setting up the esp32 IDF. While there may be simpler platforms out there, it’s not overly complex for anyone doing embedded development.

I am toying with SPARK on smaller chips. You can gradually replace parts of C code, like I think you can in Rust too, and work up to doing full-scale replacement or projects from scratch with SPARK on embedded devices, which has a lot of the benefits of Rust and then some[1][2]. I am a polyglot with certain biases/strengths in some PLs over others, so perhaps my early 80s experience with Pascal makes Ada/SPARK2014 easier for me than Rust. I understand the Ada/SPARK concepts better. I think Zig[3] will also become more popular on embedded devices for existing C programmers because its a smaller jump to make than in learning Rust, at least that has been my experience. I also enjoyed reading "Building High Integrity Applications with SPARK" which involves the , and maybe if there were a similar book for Rust, I would attempt Rust again. Because SPARK is "a formally analyzable subset of Ada 2012", it benefits from Ada's age. VTC (Vermont Technical College) launched a Cubesat into orbit on November 19, 2013 running SPARK. Rust and SPARK/Ada have been cross pollinating each other with advances in software integrity which is a win-win scenario.

[1] https://blog.adacore.com/ada-on-the-esp8266

[2] https://blog.adacore.com/how-to-prevent-drone-crashes-using-...

[3] https://ziglang.org/

Edit: I hope Amazon's involvement in Rust helps it to mature.

Out of curiousity, what do you feel Rust would need to reach maturity?

It needs more resources coming from practitioners rather than early adopters or software engineers; it needs more time to mature, and I think it will. It is just not there for me yet, and I am no longer a spring chicken. The SPARK book I cited is an excellent book written by end users with sufficient background on the subject matter and a pretty cool real world application (Cubesats), rather than by software engineers or developers. I bought another great book, "Analysable Real Time Systems: Programmed in Ada" by Alan Burns and Andy Wellings. I am learning so much from these two books. I've played with over 20 PLs in my life, and syntax is not important as it once was, although I love APL's symbols! But even in APL it is the sophistication and expressivity of the language that amazes me whenever I play with it. Verifiable software, high-integrity software, and the like are best taught by being able to study or use working and proven applications. The uptake of Rust is impressive, so all of this is starting to happen, and maturity just means anything beyond its nascence with some long term applications under its belt, not a hard date or time period.

Oh, this is exciting. I've been trying to get PlatformIO to play nicely with my ESP32C3's but it's been a pain. Only the standard Espressif RTOS tooling seems to do anything but hang the chip for some reason, and I don't know enough about PlatformIO to modify my config to make it work or to open an issue on Github.

Replacing one complex, half broken tool chain with another isn't such a bad deal, and I'm very much in favour of writing Rust instead of C(++).

I may not had to much nerves to just wrestle the initial learning curve, but my experience for PlatformIO was so bad that I do not plan to touch it ever again...

All you need is a compiler, a flash tool and maybe (nice to have but for a lot of stuff not a requirement) a JTAG debugger, so why the heck does I need that half baked, overly complex monster of pseudo IDE?

The tooling shown by ESP-rs seems nice and simple, I like that way more.

To be fair to PIO, when I used another chip (an ESP8266) the entire process was plug and play. Just install the VS Code extension, follow the wizard, and you can start with an Arduino-compatible system loop that just works. Adding libraries is easy and intuitive, as is keeping them up to date.

If you need to manually configure the tool for your devices, well... I haven't figured out how to configure it for my ESP32C3 yet, so that's not as easy as I'd hoped.

PlatformIO doesn't have an IDE, it's a dependency/compilation/flashing manager, and is fantastic. There's also PlatformIO IDE, which I've never used.

> The custom toolchain is a hindrance to developer onboarding, especially if developers have to build it themselves. We now offer a prebuilt toolchain's for all common OS's under the esp-rs/rust-build repository.

Is it possible to install and manage this pre-compiled custom toolchain with rustup? Maybe using the RUSTUP_DIST_SERVER variable to point rustup to a different server, https://rust-lang.github.io/rustup/environment-variables.htm...

Does anybody do this for other platforms? It would be rather convenient to have installable docs for stable-aarch64-apple-darwin.

as someone who occasionally dabbles in diy esp based home automation devices (mostly with esp8266) but completely new to Rust, where's the best place to get started? some code example to look at?

This repository was linked in the author's first post: https://github.com/ivmarkov/rust-esp32-std-demo

excellent! really useful, thank you!

I'm curious about this as someone who is interested in making DIY smart home products as well as their recently announced Zigbee radio module.

But genuine question, is Rust ever going to catch on in the mainstream? It seems to have a bunch of nice to have features and great optimization. But the pick up, from what I've seen, has been less than stellar.

@work we do most of our new development in rust and did so since 2019, its quite a lot more than stellar than most other things we work(ed) with, and we had some interpreted dynamic and some compiled C stuff, its an improvement from either direction..

While at work I'm doing more software development I originally studied comp. eng. and dabbled around quite a bit with embedded systems, mainly in C, ASM and tinyOS with its nesC dialect+framework. Rust is a god send in lots of areas there too, you can establish zero-cost (well some compile cost, but zero runtime ones) contracts and static guarantees with the type systems, like disallowing that code that would produce a register pull up/down configuration with a short-circuit from happening, or shared access to resources can also be done in such ways. Check the respective chapter of the rust embedded book for more info:


> But genuine question, is Rust ever going to catch on in the mainstream? It seems to have a bunch of nice to have features and great optimization. But the pick up, from what I've seen, has been less than stellar.

I'm not sure where you've gotten that impression. Rust is mainstream at this point. All the big companies (e.g. FAAMG) are using Rust. Lots of large products are: Firefox of course, but also, parts of AWS, npm, VS Code, Android. And even key infrastructure products like Linux are looking at integrating it.

I think the key is that it's mainstream at the system/platform layer, not so much the application layer (though maybe one day!). Its benefits to the former are clear and undeniable; a paradigm-shift. Its benefits to the latter are pretty mixed by comparison. Anyone who mostly hangs out at the application-layer and doesn't follow this stuff closely could miss the adoption it's getting elsewhere.

I don’t see Rust becoming mainstream in the enterprise layer anytime soon. 90% or enterprise software consists of a REST API getting JSON payloads and saving them in a DB. The most complex part is often managing the “bus factor”, rather than some technical challenge. You often need just a bit more than VB6.

Rust requires a higher cognitive cost than C# or Python, but doesn’t provide massive improvements in the areas most relevant to enterprise developers (ORMs, JSON serialization, SDKs, etc…)

All of the areas you mention as relevant to enterprise developers are things that require libraries written, potentially with APIs that lean less in the "high performance" and more on "easy to use/hard to misuse", not fundamental changes to the existing language or tooling. I personally think that the big surprise with Rust will be how flexible it can be, covering a wider range of use cases than it might look at first.

Any company that does try to work with Rust today in any vertical slightly outside of what is considered "mainstream" will likely end up having to write their own libraries for things that are already available in other languages, but that's a factor of the ecosystem's age.

Though dependency management is quite easy to manage in rust (as with many high level languages) whereas I would argue dependency management isn't as simple in C/C++ which should boost library consumption and creation.

I know depending on boost or qt might be really easy, but the amount of different toolsets you must know to depend on randomlib is too damn high. I wish though that it doesn't end up like npm, I also hope there'll be some kind of "meta standard library" which integrates different mainstream building block libraries into something that's easy to consume coherently.

I consider most web-services - certainly glue code - to be at the "application layer". Of course these definitions are always fuzzy.

Which isn't to say Rust is never the right choice for those, it's just a more complicated question that's highly project-specific. Which is why it isn't mainstream there like it is in other places.

>Rust is mainstream For sure it depends what you mean by mainstream. If a FAANG uses language X, it's language X mainstream?

I'd venture to say that to be considered mainstream a language has to at least pass 1% threshold in Tiobe index (or the equivalent in Redmonk or others).

If Rust is mainstream, then Fortran is über mainstream

I would argue that Fortran _is_ "über mainstream" - if you look at computing as a whole. It may not be used extensively for CRUD applications, but it is part of the bedrock of basically all computing. And there are some niches where it is the main/only language.

Rust will likely end up in a similar place - enormously useful in its niche, foundational for infrastructure outside, and with enough uptake and stability to make a career out of. I don't think anyone expects it to eclipse popular dynamic languages for web development, but it might make inroads on C and C++ in areas where active development is still needed.

The rankings in that index are highly suspect. It has Visual Basic at #6 and Classic Visual Basic as #11. Meanwhile Kotlin is down in position #38 and TypeScript at #46 beneath COBOL, PROLOG, Scratch and Logo!

(And FWIW Rust is #26)

I understand that it is very popular and is increasing adoption. But I was more targeting the embedded systems/hardware. Obviously this blog post is a step in that direction, but I'm still curious if hardware manufacturers will want to spend time adopting it.

> I'm still curious if hardware manufacturers will want to spend time adopting it.

The interesting thing I'm observing[0] is that embedded developers aren't wasting any time waiting for hardware manufacturers to do anything about Rust because they know manufacturers...well, let's express it as: "just don't care about software".

Bluntly, regardless of whether it's perfect or not, Rust is currently pretty much the only hope for devs who are desperate to move on from C for embedded work and if they have reverse engineer every last proprietary bitstream, protocol & application they will.

It's not just about the language itself (which depending on one's perspective has both pluses & minuses) but also the ecosystem/tooling (e.g. libraries with `no_std` support, build/test/doc systems, etc). (And, from my perspective, the community from which this has all grown--and why.)

Maybe it won't succeed but it won't be for lack of trying. :D

Also, one of the interesting aspects of Rust for me is how broad the domains of application are--using the same language from microcontroller level, through UEFI/firmware, OS, applications, & web is pretty appealing and leads to easier migration between domains.

[0] Including in a comment a few comments down from this one (when I first read it): https://news.ycombinator.com/item?id=29001985

In what space? If you're talking about embedded, it's going to be pretty slow for industry to start using rust en masse. There's a huge amount of inertia in embedded, and the developers are somewhat beholden to manufacturers to release tooling around rust.

In the software space, rust is being used by quite a few companies [0].

0: https://www.rust-lang.org/production/users

It may be true that manufacturers are ignoring Rust but that certainly does not stop or hinder me. Tools like svd2rust mean I only need to rely on the accuracy of their svd files (industry standard register maps) - see https://github.com/rust-embedded/svd2rust

Additionally, I use vanilla VS Code and rust analyser so no need to use manufacturer supplied lock-in IDEs. There are many compiler targets to choose from for cross compilation and tools like probe-run to flash chips.

One major issue is lack of manufacturer provided code examples written in Rust. For that I rely on the Rust community. A typical example being nrf-hal for Nordic Bluetooth chips.

FWIW, the Rust embedded size also lists a few production embedded users: https://www.rust-lang.org/what/embedded

Rust is gaining momentum at a decent pace IMO. It's not necessarily a web technology so expect slower adoption but still it's been steadily growing.

> It's not necessarily a web technology

And honestly, I've been toying around with an Actix web server written in Rust, and the experience is not bad. As someone new to Rust, the main pain points have been along the lines of figuring out how to type a parameter to accept both a database pool and a database transaction (which turns out to be quite hard to figure out). Other than that kind of friction, the experience has been nice.

Yeah, I personally feel Rust is the future for web. The community just needs to invest in itself to build a bigger ecosystem. The rest will follow.

If you want to try out rust for web, check out this project: https://github/wulf/create-rust-app

I think many people are trying to make Rust real deal and some of them make really good job. There was a guy who develops Linux ABI compatible kernel in rust, Tor is being rewritten in to Rust and some of the projects are just amazing.

I believe it will catch on as soon as people realize it's a C performance with modern syntax and memory safety mitigating most of the security flaws and bugs introduced by mismanaged memory.

I fell in love as soon as I saw descriptive scalar types like "i32".

Are there specific areas where you would expect to see greater adoption at this point on the curve? "Mainstream" adoption of a brand-new language takes time, and it's still early on the curve for Rust.

If anything, the hype-train might make it seem like it's a more mature ecosystem than it really is. The questions to ask are, what's causing the hype, and does the product deliver.

From what I've seen in my company there seems to be some resistance to rust due to it already having a lot of code written in other languages and them kinda of being the default go to choice.

does esp32-rs have working wifi yet?

At first, I thought the article was about oxidizing chips.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact