Rust on Espressif chips
mabez.dev
mabez.dev
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?
FYI: There's already an official rust based rewrite of it: https://github.com/esp-rs/espflash
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.
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?
[0]: https://www.espressif.com/en/products/socs/esp32-c3
[1]: https://www.mouser.de/new/espressif/espressif-esp32c3wroom02...
> ESP32-C3 is a single-core, 32-bit, RISC-V-based MCU with 400KB of SRAM, which is capable of running at 160MHz
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.
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.
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:
https://docs.rust-embedded.org/book/static-guarantees/index....
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.
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.
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.
Personally, I've never experienced any better IDE than Visual Studio. I would call it bleeding edge.
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.
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.
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/
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.
Not having to install custom Rust toolchain for Xtensa chips was nice, too.
[1] https://blog.adacore.com/ada-on-the-esp8266
[2] https://blog.adacore.com/how-to-prevent-drone-crashes-using-...
Edit: I hope Amazon's involvement in Rust helps it to mature.
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(++).
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.
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.
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...
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.
In the software space, rust is being used by quite a few companies [0].
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.
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.
If you want to try out rust for web, check out this project: https://github/wulf/create-rust-app
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.
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…)
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.
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.
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.
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
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
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.
(And FWIW Rust is #26)
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".
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.
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:
https://docs.rust-embedded.org/book/static-guarantees/index....