[HN Gopher] Rust on Espressif chips
___________________________________________________________________
Rust on Espressif chips
Author : lukastyrychtr
Score : 204 points
Date : 2021-10-26 14:29 UTC (8 hours ago)
(HTM) web link (mabez.dev)
(TXT) w3m dump (mabez.dev)
| eklbt wrote:
| 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.
| RuiJCS wrote:
| 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.
| bitdivision wrote:
| 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
| davidhyde wrote:
| 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.
| tlamponi wrote:
| FWIW, the Rust embedded size also lists a few production
| embedded users: https://www.rust-lang.org/what/embedded
| chewmieser wrote:
| 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.
| Wulf_ wrote:
| 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 my project:
| https://github/wulf/create-rust-app
| allochthon wrote:
| > 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.
| nicoburns wrote:
| > 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.
| DeathArrow wrote:
| >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 uber mainstream
| nebopolis wrote:
| I would argue that Fortran _is_ "uber 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.
| nicoburns wrote:
| 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)
| brundolf wrote:
| 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.
| [deleted]
| mmarq wrote:
| 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...)
| brundolf wrote:
| 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.
| estebank wrote:
| 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.
| carlhjerpe wrote:
| 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.
| eklbt wrote:
| 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.
| follower wrote:
| > 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
| po1nt wrote:
| 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".
| trevyn wrote:
| 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.
| tlamponi wrote:
| @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:
|
| https://docs.rust-embedded.org/book/static-guarantees/index....
| aulin wrote:
| 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?
| pfes wrote:
| This repository was linked in the author's first post:
| https://github.com/ivmarkov/rust-esp32-std-demo
| aulin wrote:
| excellent! really useful, thank you!
| po1nt wrote:
| 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?
| pfes wrote:
| 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/
| dljsjr wrote:
| 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.
| pfes wrote:
| 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.
| dljsjr wrote:
| I stand corrected, that's a useful template project.
| Thanks for linking!
| tlamponi wrote:
| 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
| tlamponi wrote:
| > 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.
| po1nt wrote:
| 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?
| tlamponi wrote:
| 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
| kingosticks wrote:
| 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
| tlamponi wrote:
| 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.
| bri3d wrote:
| 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.
| tlamponi wrote:
| 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.
| kingosticks wrote:
| "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.
| tlamponi wrote:
| 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..
| kingosticks wrote:
| 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.
| conk wrote:
| 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.
| tinco wrote:
| 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.
| the__alchemist wrote:
| 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.
| po1nt wrote:
| 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.
| steveklabnik wrote:
| In general, Rust development on Windows, including at least
| the embedded platforms I work with (ARM), is identical to
| Linux or Mac.
| foldr wrote:
| As sibling says, for embedded toolchains Windows is often the
| best supported platform.
| bfrog wrote:
| Nothing like proprietary tooling to really make everything
| 1000% more painful
| outside1234 wrote:
| I'm not sure of the situation with ESP but in many embedded
| environments you HAVE TO use Windows for development.
| MarkMarine wrote:
| Not the situation for ESP, but the C++ pain is real. Once
| that is sorted, it works great on mac.
| coupdejarnac wrote:
| 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.
| carlmr wrote:
| >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.
| qbasic_forever wrote:
| 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.
| Hendrikto wrote:
| At first, I thought the article was about oxidizing chips.
| nextaccountic wrote:
| > 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...
| hedgehog wrote:
| Does anybody do this for other platforms? It would be rather
| convenient to have installable docs for stable-aarch64-apple-
| darwin.
| jeroenhd wrote:
| 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(++).
| tlamponi wrote:
| 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.
| jeroenhd wrote:
| 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.
| eggy wrote:
| 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.
| jamincan wrote:
| Out of curiousity, what do you feel Rust would need to reach
| maturity?
___________________________________________________________________
(page generated 2021-10-26 23:01 UTC)