15 ms·

Rust for Embedded Systems: Current state, challenges and open problems

189 points by Sindisil 3y ago

bruce343434 3y ago
[flagged]
- deleted 3y ago
  [deleted]
nindalf 3y ago
The overall argument that Rust's use in embedded has a long way to go is fairly accurate. A foundational crate like embedded-hal reached 1.0 only 2 months ago, 8 years after Rust 1.0. On the other hand, this crate reaching 1.0 means the rest of the ecosystem can now mature alongside it. The paper could use a few minor corrections and improvements. For example, they go through thousands of crates in crates.io to give the impression of completeness, but it would have been better to go though a more curated source like https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust. It doesn't matter if the quality of random one off crates that someone hacked over a weekend is poor, it does matter if the crates recommended by the community are poor. But I suppose their analysis would look impressive then. The other nit is that they think that the existence of even one instance of unsafe is a problem. This is a mistake that people unfamiliar with Rust make.
- Kototama 3y ago
  You mean embedded-hal, not embedded-hat :-)
  - nindalf 3y ago
    Haha thanks for the correction. Autocorrect got me.
fusslo 3y ago
my takeaways: 1. https://arewertosyet.com/ https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integrating with Existing codebase (32%) ; Organization constraints and certification requirements (30%)" 5. "The second major (26%) issue is debugging, which is expected because, as explained in Section 2, embedded systems follow an asynchronous and event-driven design. This results in frequent cross-language domain interactions and makes debugging hard." I would adopt rust if it were easy to get up and running just while(1) loop applications.
- dralley 3y ago
  >I would adopt rust if it were easy to get up and running just while(1) loop applications. Doesn't embassy_rs make that pretty easy?
  - fusslo 3y ago
    i found out about embassy via the link in #1, looking at it now reading the readme gets me pretty excited tho
- the__alchemist 3y ago
  > I would adopt rust if it were easy to get up and running just while(1) loop applications. It is: Install the toolchain (eg `rustup target add thumbv7hibf`); install probe-rs; `cargo run`. I think getting applications up and running in embedded rust is one of its strengths.
- jcranmer 3y ago
  > 2. there are tools to convert c to rust (I dont know if I'd trust this..) The core C specification by itself isn't all that complicated of a language; a C-to-Rust transpiler is a pretty doable project. The main issues here are that a) a lot of the code you'd likely want to convert is likely to be reliant on non-standard extensions b) there's a lot of undefined behavior which you probably want to have somewhat more defined behavior on, especially in embedded contexts c) the real goal for a lot of this automated conversion is to do the conversion once and work well enough that you don't have to audit the result of the conversion, and because of especially the previous point, it's really hard to get that level of trust for C code. The existing c2rust converter works by creating the clang AST and then lowering that to Rust source code, which I'm not sure is a path that would lead me to high confidence in the converted code due to the potential impedance mismatch in understanding the clang AST. A custom C frontend is probably a better match here for a long term project (C, unlike C++, is feasible to build your own compiler from scratch), or maybe another project idea is to convert LLVM IR to Rust and ditch the C frontend entirely.
AlotOfReading 3y ago
These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation. I've found very few projects where a bit of poking can't turn up memory safety issues. Even people who are far more skilled programmers than I am routinely write silly mistakes. Unfortunately the response I often hear to bringing these issues up after the code exists is "it's working code, why should I care about these theoretical issues?"
- adameasterling 3y ago
  > I've found very few projects where a bit of poking can't turn up memory safety issues. I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.
  - AlotOfReading 3y ago
    Made it more clear in the original post that I was talking about the correctness of C and C++ code. I haven't observed any notable issues with this in Rust compared to similar languages, but I also don't have the same depth of experience building large systems in it to show me the error of my ways yet.
- dboreham 3y ago
  I had to read this a couple of times, but I suspect this is about non-rust code, when you cite correctness of code, yes? People don't want to use rust because they think their janky C/C++ is just fine.
- jcelerier 3y ago
  > People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.
gaze 3y ago
[flagged]
mikeInAlaska 3y ago
I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust. I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.
- monocasa 3y ago
  Bare metal or on linux?
  - mikeInAlaska 3y ago
    Linux
atoav 3y ago
As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.
- tamimio 3y ago
  Spot on!
- worik 3y ago
  > Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I had a sense this a priority for the Rust Central Committee, so I had a quick look https://docs.rust-embedded.org/book/interoperability/c-with-rust.html https://docs.rust-embedded.org/book/interoperability/c-with-... I have not had to use it yet, looking for a reason.
- znpy 3y ago
  > As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. Maybe the mindset of the industry as well? Not sure if things have changed (and if so, how) but 9-10 years ago when i was in university I had an interview with a company that did embedded systems stuff. While talking about my competencies I mentioned I was able to create cross-toolchain if they were interested and the guy (he was kinda like the CTO iirc) abruptly interrupted me and just said: "no. just no. we always and only use the vendor's BSP (board support package). we don't care about anything else. should there be any kind of issue we want to be able to ring them and get them to fix the issue.". How do you get people (or an industry?) with such a mindset to just use something because it's trendy? My guess is that industry will wait another 10-15 years until some vendor big enough ships a rust toolchain as a BSP. Other vendors will follow. Then Rust on embedded systems will flourish.
mips_r4300i 3y ago
How long before I can visually debug rust on MCUs with source level stepping in my IDE? Til then, no way to switch.
- explodingwaffle 3y ago
  You mean, like this? https://probe.rs/docs/tools/debugger/ https://probe.rs/docs/tools/debugger/
  - mips_r4300i 3y ago
    Thanks, that's more what I was looking for. Looks like it is still pretty early stuff but could be useful in the future.
- the__alchemist 3y ago
  What do you mean by visually debug? If you install `probe-rs` and do `cargo run`, you can print whatever you want to console; not related to the IDE. (Not sure if this is what you're looking for, or something else)
  - mips_r4300i 3y ago
    Visual Studio-type ide debugging, viewing structs, run to cursor, etc.
    - pjmlp 3y ago
      While not Visual Studio C++ level, using CodeLLDB in VS is already quite good. https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb https://marketplace.visualstudio.com/items?itemName=vadimcn....
- RealityVoid 3y ago
  Like... zero days? You can just plop the .elf in gdb and then debug on target. I just did it on a riscv mcu just a couple hours ago. Rust is there on the embedded, the only thing missing is people realising it's there.
throwaway17_17 3y ago
The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder about the applicability of these percentages to non-RTOS programming. I find it very interesting that 81% of CVE's are allocated to Out-of-Bound Read/Writes, with writes being the larges percent of those obviously. Has there been any CVE cause analysis performed and publicly available? If so and the percentages bear out similarly to RTOS's across a spectrum of application/system types then there may be some clear cost/benefit analysis needed at the programming language design stage. Rust is a complex language with a complex type and lifetime system to achieve memory safety, and it is not an uncommon refrain that a simpler 'safe' language would be appreciated by many developers. If 80% of CVE's come from Read/Write errors on array access, then a language that enforces strict memory access semantics, but forgoes the rest of Rust's complexity regarding lifetimes and type system complexity would achieve a very large portion of exploit prevention at a minimal cost. Additionally, if you prevent Null types in the type system the language would then prevent 90% of CVE causes, again with a minimal amount of complexity. I'm not certain that the above is correct, if the percentages play out in the large, or that devs would actively switch to a considerably safer, while being simpler language. But it certainly is thought provoking.
- bobajeff 3y ago
  I'm with you on that. In fact I think it's needed to use something less complex than rust in order to prevent other bugs from cropping up due to misunderstood parts of language. C has some bad things it does by default that lead to terrible bugs. I imagine many of them can be addressed without complex move semantics added to it. Some promising work I've seen in this area had been the adoption of language level allocators in zig and Odin. Many newer languages also have better arrays come with length information. And array languages like APL avoid out of bounds errors. I don't think you have to go full ML style type checker (or borrow checker) to prevent bugs.
- pornel 3y ago
tamimio 3y ago
Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.
- the__alchemist 3y ago
  What sorts of parts? Most should have register-level APIs in the datasheet. That doesn't mean integrating is easy though, compared to the SDK.
  - svnt 3y ago
    Beginning by using the register listings in the datasheet is what parent meant by “from scratch.” Anything more would have been reverse engineering.
  - tamimio 3y ago
    > What sorts of parts? A lot of parts I had to work with didn’t have it, last one a couple months ago for example was a guided parachute for a drone dropper, I ended up making the driver from scratch that interfaced with the serial io.
- xyst 3y ago
  What’s wrong with wrapping the C headers in rust? Seems possible to me, although a bit labor intensive depending on the C/C++ lib — https://docs.rust-embedded.org/book/interoperability/c-with-rust.html https://docs.rust-embedded.org/book/interoperability/c-with-...
  - tamimio 3y ago
    Nothing is wrong with that, it’s rather a workaround, ultimately I am trying to have one language only including the UI too (been playing with egui),so I don’t have to use JavaScript. https://github.com/emilk/egui https://github.com/emilk/egui
0xbeefeed 3y ago
[dead]
sheepybloke 3y ago
Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.
- steveklabnik 3y ago
  It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
  - infamouscow 3y ago
    It's a show stopper when size matters and you can't fit the binaries into flash. I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools. If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with paying rent, because you're not going to be employed much longer.
    - steveklabnik 3y ago
      My point is that you can always fit the binaries into flash. There’s no inherent overhead.
      - infamouscow 3y ago
        That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically. But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.
127 3y ago
I've been trying out embassy-rs and what is really exciting that you might get RTOS abilities, without actually using an RTOS. Just native Rust, with some smart abstractions. Still prefer C, but the Rust embedded community seems to be cooking up something very interesting.
SomeoneFromCA 3y ago
"Embedded" is a diverse concept. No need for Rust on ATtiny with all variables static and Harvard architecture. In fact, even C often is overkill, and Assembler is a better choice for a simple LED flasher or really tight high performance loop.
grawp 3y ago
rtic-rs
DriftRegion 3y ago
I think when bringing up embedded rust it is necessary to specify an application. For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_baremetal https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_... )
ladyanita22 3y ago
I wonder how would the performance of Rust be without the runtime checks and the std_library. And why is the std_library less performant than, let's say, C's counterpart?
junon 3y ago
If you're using Stm32s or Nordiks (among a few others) then I cannot recommend enough the Embassy framework. I used it for a custom board I made and it not only consumed less power overall due to the automatic chip sleep state handling but has been drastically easier to work with than the provided C firmware. Developer is also super responsive on Matrix and a nice guy. https://GitHub.com/embassy-rs https://GitHub.com/embassy-rs
bunchandrew 3y ago
[dead]

189 points by Sindisil 3y ago

bruce343434 3y ago

[flagged]

deleted 3y ago
[deleted]

nindalf 3y ago

The overall argument that Rust's use in embedded has a long way to go is fairly accurate. A foundational crate like embedded-hal reached 1.0 only 2 months ago, 8 years after Rust 1.0. On the other hand, this crate reaching 1.0 means the rest of the ecosystem can now mature alongside it. The paper could use a few minor corrections and improvements. For example, they go through thousands of crates in crates.io to give the impression of completeness, but it would have been better to go though a more curated source like https://github.com/rust-embedded/awesome-embedded-rust https://github.com/rust-embedded/awesome-embedded-rust. It doesn't matter if the quality of random one off crates that someone hacked over a weekend is poor, it does matter if the crates recommended by the community are poor. But I suppose their analysis would look impressive then. The other nit is that they think that the existence of even one instance of unsafe is a problem. This is a mistake that people unfamiliar with Rust make.

Kototama 3y ago
You mean embedded-hal, not embedded-hat :-)
- nindalf 3y ago
  Haha thanks for the correction. Autocorrect got me.

fusslo 3y ago

my takeaways: 1. https://arewertosyet.com/ https://arewertosyet.com/ to track rust RTOSes and their status 2. there are tools to convert c to rust (I dont know if I'd trust this..) 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). Most of these crates are generated using svd2rust utility" 4. developers considered but rejected rust because: "Lack of Support for MCUs (36%) ; Difficulty Integrating with Existing codebase (32%) ; Organization constraints and certification requirements (30%)" 5. "The second major (26%) issue is debugging, which is expected because, as explained in Section 2, embedded systems follow an asynchronous and event-driven design. This results in frequent cross-language domain interactions and makes debugging hard." I would adopt rust if it were easy to get up and running just while(1) loop applications.

dralley 3y ago
>I would adopt rust if it were easy to get up and running just while(1) loop applications. Doesn't embassy_rs make that pretty easy?
- fusslo 3y ago
  i found out about embassy via the link in #1, looking at it now reading the readme gets me pretty excited tho
the__alchemist 3y ago
> I would adopt rust if it were easy to get up and running just while(1) loop applications. It is: Install the toolchain (eg `rustup target add thumbv7hibf`); install probe-rs; `cargo run`. I think getting applications up and running in embedded rust is one of its strengths.
jcranmer 3y ago
> 2. there are tools to convert c to rust (I dont know if I'd trust this..) The core C specification by itself isn't all that complicated of a language; a C-to-Rust transpiler is a pretty doable project. The main issues here are that a) a lot of the code you'd likely want to convert is likely to be reliant on non-standard extensions b) there's a lot of undefined behavior which you probably want to have somewhat more defined behavior on, especially in embedded contexts c) the real goal for a lot of this automated conversion is to do the conversion once and work well enough that you don't have to audit the result of the conversion, and because of especially the previous point, it's really hard to get that level of trust for C code. The existing c2rust converter works by creating the clang AST and then lowering that to Rust source code, which I'm not sure is a path that would lead me to high confidence in the converted code due to the potential impedance mismatch in understanding the clang AST. A custom C frontend is probably a better match here for a long term project (C, unlike C++, is feasible to build your own compiler from scratch), or maybe another project idea is to convert LLVM IR to Rust and ditch the C frontend entirely.

AlotOfReading 3y ago

These are all real issues with Rust, though it's worth noting that many of the integration challenges mentioned also apply to external code written in C and C++. Some of the survey responses highlight one of the biggest hurdles to rust adoption I've experienced though: Rust has an education problem. People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation. I've found very few projects where a bit of poking can't turn up memory safety issues. Even people who are far more skilled programmers than I am routinely write silly mistakes. Unfortunately the response I often hear to bringing these issues up after the code exists is "it's working code, why should I care about these theoretical issues?"

adameasterling 3y ago
> I've found very few projects where a bit of poking can't turn up memory safety issues. I'm working on a Rust project right now, and I'm probably one of those people who are overestimating the correctness of my code! I would love to know about what sorts of memory safety issues you often uncover.
- AlotOfReading 3y ago
  Made it more clear in the original post that I was talking about the correctness of C and C++ code. I haven't observed any notable issues with this in Rust compared to similar languages, but I also don't have the same depth of experience building large systems in it to show me the error of my ways yet.
dboreham 3y ago
I had to read this a couple of times, but I suspect this is about non-rust code, when you cite correctness of code, yes? People don't want to use rust because they think their janky C/C++ is just fine.
jcelerier 3y ago
> People dramatically overestimate the correctness of their [C/C++] code and underestimate the potential severity of failures to meet that expectation Really depends on the field. I heard more than once in my life now that it's better to reboot every night than spend even an afternoon of engineering trying to fix memory leaks.

gaze 3y ago

[flagged]

mikeInAlaska 3y ago

I spent a weekend with Rust, a Raspi4, and our buddy GPT about six months ago. In that weekend I was able to get the Raspi controlling a OLED display via SPI with an SSD1306 controller. I thought it was a fairly clean port from C++, and GPT was well educated on how to use the RASPI SPI and I2C busses from Rust. I don't think I would be able to approach it on an ESP32 or AVR xMega or some other real microcontroller.

monocasa 3y ago
Bare metal or on linux?
- mikeInAlaska 3y ago
  Linux

atoav 3y ago

As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. So let's say I happen to work with a MCU that is well supported in Rust, what if I want to connect it to a popular OLED display? Is there a library for that? If so, does it work? If it works, does it have the needed features? Now maybe I am incredibly lucky and all of that works, what about a popular gyro IC? Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I will certainly check back on the state of Rust on embedded every now and then, but as of now C++ is my goto.

tamimio 3y ago
Spot on!
worik 3y ago
> Granted, there is probably some way to interface the Rust code with C code, but is that gonna work without turning it into a day of research? I had a sense this a priority for the Rust Central Committee, so I had a quick look https://docs.rust-embedded.org/book/interoperability/c-with-rust.html https://docs.rust-embedded.org/book/interoperability/c-with-... I have not had to use it yet, looking for a reason.
znpy 3y ago
> As a rust programmer that programs C++ on embedded, the main thing preventing adoption is the ecosystem. Maybe the mindset of the industry as well? Not sure if things have changed (and if so, how) but 9-10 years ago when i was in university I had an interview with a company that did embedded systems stuff. While talking about my competencies I mentioned I was able to create cross-toolchain if they were interested and the guy (he was kinda like the CTO iirc) abruptly interrupted me and just said: "no. just no. we always and only use the vendor's BSP (board support package). we don't care about anything else. should there be any kind of issue we want to be able to ring them and get them to fix the issue.". How do you get people (or an industry?) with such a mindset to just use something because it's trendy? My guess is that industry will wait another 10-15 years until some vendor big enough ships a rust toolchain as a BSP. Other vendors will follow. Then Rust on embedded systems will flourish.

mips_r4300i 3y ago

How long before I can visually debug rust on MCUs with source level stepping in my IDE? Til then, no way to switch.

explodingwaffle 3y ago
You mean, like this? https://probe.rs/docs/tools/debugger/ https://probe.rs/docs/tools/debugger/
- mips_r4300i 3y ago
  Thanks, that's more what I was looking for. Looks like it is still pretty early stuff but could be useful in the future.
the__alchemist 3y ago
What do you mean by visually debug? If you install `probe-rs` and do `cargo run`, you can print whatever you want to console; not related to the IDE. (Not sure if this is what you're looking for, or something else)
- mips_r4300i 3y ago
  Visual Studio-type ide debugging, viewing structs, run to cursor, etc.
  - pjmlp 3y ago
    While not Visual Studio C++ level, using CodeLLDB in VS is already quite good. https://marketplace.visualstudio.com/items?itemName=vadimcn.vscode-lldb https://marketplace.visualstudio.com/items?itemName=vadimcn....
RealityVoid 3y ago
Like... zero days? You can just plop the .elf in gdb and then debug on target. I just did it on a riscv mcu just a couple hours ago. Rust is there on the embedded, the only thing missing is people realising it's there.

throwaway17_17 3y ago

The paper may be Rust specific, but I found the CVE break down chart on p. 25 interesting. When looking at the percentages of the CVE causes (focused on the 59 bugs classified as those Rust prevents) I got the following: Out of Bounds Reads => 18.6%; Out of Bounds Writes => 62.7%; Null-Ptr Deref => 8.5%; Use-After-Free => 5.1%; Type Confusion, Uninitialized Pointer Access, Memory Leak => EACH 1.5%; I have to wonder about the applicability of these percentages to non-RTOS programming. I find it very interesting that 81% of CVE's are allocated to Out-of-Bound Read/Writes, with writes being the larges percent of those obviously. Has there been any CVE cause analysis performed and publicly available? If so and the percentages bear out similarly to RTOS's across a spectrum of application/system types then there may be some clear cost/benefit analysis needed at the programming language design stage. Rust is a complex language with a complex type and lifetime system to achieve memory safety, and it is not an uncommon refrain that a simpler 'safe' language would be appreciated by many developers. If 80% of CVE's come from Read/Write errors on array access, then a language that enforces strict memory access semantics, but forgoes the rest of Rust's complexity regarding lifetimes and type system complexity would achieve a very large portion of exploit prevention at a minimal cost. Additionally, if you prevent Null types in the type system the language would then prevent 90% of CVE causes, again with a minimal amount of complexity. I'm not certain that the above is correct, if the percentages play out in the large, or that devs would actively switch to a considerably safer, while being simpler language. But it certainly is thought provoking.

bobajeff 3y ago
I'm with you on that. In fact I think it's needed to use something less complex than rust in order to prevent other bugs from cropping up due to misunderstood parts of language. C has some bad things it does by default that lead to terrible bugs. I imagine many of them can be addressed without complex move semantics added to it. Some promising work I've seen in this area had been the adoption of language level allocators in zig and Odin. Many newer languages also have better arrays come with length information. And array languages like APL avoid out of bounds errors. I don't think you have to go full ML style type checker (or borrow checker) to prevent bugs.
pornel 3y ago

tamimio 3y ago

Personally in the past ~2 years I have been trying to shift my code base to rust when it comes to robotics and drones software, the biggest issue is the integration part, most “addons” that you can integrate with the robots like Lidar and other sensors come with the usual SDKs in C/C++ or even python. Additionally, most of X-rust converters don’t really work so you end up rewriting it from scratch.

the__alchemist 3y ago
What sorts of parts? Most should have register-level APIs in the datasheet. That doesn't mean integrating is easy though, compared to the SDK.
- svnt 3y ago
  Beginning by using the register listings in the datasheet is what parent meant by “from scratch.” Anything more would have been reverse engineering.
- tamimio 3y ago
  > What sorts of parts? A lot of parts I had to work with didn’t have it, last one a couple months ago for example was a guided parachute for a drone dropper, I ended up making the driver from scratch that interfaced with the serial io.
xyst 3y ago
What’s wrong with wrapping the C headers in rust? Seems possible to me, although a bit labor intensive depending on the C/C++ lib — https://docs.rust-embedded.org/book/interoperability/c-with-rust.html https://docs.rust-embedded.org/book/interoperability/c-with-...
- tamimio 3y ago
  Nothing is wrong with that, it’s rather a workaround, ultimately I am trying to have one language only including the UI too (been playing with egui),so I don’t have to use JavaScript. https://github.com/emilk/egui https://github.com/emilk/egui

0xbeefeed 3y ago

[dead]

sheepybloke 3y ago

Honestly, the biggest thing that concerns me with using Rust for embedded is the size of the crates. We were looking to do some packages for a product, and the Rust packages were huge compared to the C++ ones. Granted, this was mostly because the C++ ones could use .so's, while Rust had to compile those into the crate, but this is a huge issue when doing OTA updates.

steveklabnik 3y ago
It's just something you have to care about, but it's not a show-stopper. We use a bunch of crates in our projects at work, I left some example sizes in a comment a while back https://news.ycombinator.com/item?id=34032824 https://news.ycombinator.com/item?id=34032824
- infamouscow 3y ago
  It's a show stopper when size matters and you can't fit the binaries into flash. I'm sure "sorry for getting everyone to switch to this unestablished language" will go over very well with your boss and upper management. At least in C and C++ you can blame your tools. If you've stupidly convinced management the existing tooling is shit, then you've got a problem. And I don't mean a technical one, I mean a problem with paying rent, because you're not going to be employed much longer.
  - steveklabnik 3y ago
    My point is that you can always fit the binaries into flash. There’s no inherent overhead.
    - infamouscow 3y ago
      That's great it works well for AMD64 Linux ELF files. I would be surprised if it didn't given the toolchain seems to have been designed around that triple specifically. But the majority of embedded platforms are not booting or running AMD64 Linux, they're running ARMv{6,7,8}, MIPS, or 32-bit RISC-V chips.

127 3y ago

I've been trying out embassy-rs and what is really exciting that you might get RTOS abilities, without actually using an RTOS. Just native Rust, with some smart abstractions. Still prefer C, but the Rust embedded community seems to be cooking up something very interesting.

SomeoneFromCA 3y ago

"Embedded" is a diverse concept. No need for Rust on ATtiny with all variables static and Harvard architecture. In fact, even C often is overkill, and Assembler is a better choice for a simple LED flasher or really tight high performance loop.

grawp 3y ago

rtic-rs

DriftRegion 3y ago

I think when bringing up embedded rust it is necessary to specify an application. For low level, hard realtime control and interrupt handling rust gets in the way. Many embedded applications stop here. For things like parsing, protocol stacks and business logic rust has a clear advantage. Interoperability with C is therefore essential. The current situation is good for ARM and RISC (ESP32) but impossible for weirder stuff like C28x. (See my demo here: https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_baremetal https://github.com/driftregion/bazel-c-rust-x86_linux-armv7_... )

ladyanita22 3y ago

I wonder how would the performance of Rust be without the runtime checks and the std_library. And why is the std_library less performant than, let's say, C's counterpart?

junon 3y ago

If you're using Stm32s or Nordiks (among a few others) then I cannot recommend enough the Embassy framework. I used it for a custom board I made and it not only consumed less power overall due to the automatic chip sleep state handling but has been drastically easier to work with than the provided C firmware. Developer is also super responsive on Matrix and a nice guy. https://GitHub.com/embassy-rs https://GitHub.com/embassy-rs

bunchandrew 3y ago

[dead]