Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Rust on Espressif chips

mabez.dev

Post reply on HN
Print view View original

41–50 of 71 posts

Re: Rust on Espressif chips

#41

Post by kingosticks »

tlamponi wrote: post #33
kingosticks wrote: post #21

Earlier quoted context omitted.

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 https://www.espressif.com/en/news/ESP32_C3

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.

"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.

Re: Rust on Espressif chips

#42

Post by nicoburns »

DeathArrow wrote: post #28
nicoburns wrote: post #7

Earlier quoted context omitted.

> 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,…

>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

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)

Re: Rust on Espressif chips

#43

Post by follower »

eklbt wrote: post #14
nicoburns wrote: post #7

Earlier quoted context omitted.

> 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,…

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

Re: Rust on Espressif chips

#44

Post by nextaccountic »

> 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...

Re: Rust on Espressif chips

#45

Post by _xyub »

chewmieser wrote: post #6
eklbt wrote: post #2

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.

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.

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

Re: Rust on Espressif chips

#46

Post by tlamponi »

kingosticks wrote: post #41
tlamponi wrote: post #33

Earlier quoted context omitted.

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.

"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..

Re: Rust on Espressif chips

#47

Post by estebank »

mmarq wrote: post #23
brundolf wrote: post #12

Earlier quoted context omitted.

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…

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.

Re: Rust on Espressif chips

#48

Post by tlamponi »

bri3d wrote: post #39
tlamponi wrote: post #33

Earlier quoted context omitted.

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 man…

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.

Re: Rust on Espressif chips

#49

Post by hedgehog »

nextaccountic wrote: post #44

> 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/envi…

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

Re: Rust on Espressif chips

#50

Post by outside1234 »

tinco wrote: post #22
po1nt wrote: post #4

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 unst…

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 bl…

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