5 ms·

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 kno

by 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.
- jandrese 3y ago
  The big problem is just the fundamental mismatch between what Rust requires and what you can do in C, especially with embedded code. If the library in question handles interrupts by jumping to an interrupt handler that updates some shared state you're going to have a bad time converting that into safe Rust.
- Animats 3y ago
  > C-to-Rust transpiler is a pretty doable project. It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics. An intelligent C to Rust translator would be a big win. You'd need to annotate the input C with info about how long arrays are and such, to guide the translator. It might be possible to use an LLM to analyze the code and provide annotations. Usually, C code does have array length info; it's just not in a form that the language ties to the array itself. If you see char* buf = malloc(len); the programmer knows that "buf" has length "len", but the programmer does not. Something needs to annotate "buf" with that info so that the translator knows it. Then the translator can generate Rust: let mut buf = vec![0;len]; The payoff comes at calls. C code: int write_to_device(char* buf, size_t len) is a common idiom. LLMs are good at idioms. At this point, one can guess that this is equivalent to fn write_to_device(buf: &[u8]) -> i32 in Rust. Then the translator has to track "len" to make sure that assert_eq!(buf.len(), len); is either provably true, or put in that assert to check it at run time. So that's a path to translation into safe Rust. Funding could probably be obtained from Homeland Security for this, given the new White House level interest in safe languages and the headaches being caused by the cyber war. Is CVS still down?
  - jcranmer 3y ago
    > It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics. The idea behind the current c2rust tool is that you'd do a one-shot conversion to Rust and then gradually do refactoring passes over the barely-Rust code to convert it to correct C code. The focus is on preserving semantics of C over writing anything close to idiomatic (cue a + b being translated to a.wrapping_add(b) all the time, e.g.). Which is an approach, but I'm not sure it ends up providing any value over "set your system to compile both C and Rust into a final image and then slowly move stuff from the C to the Rust side as appropriate" in practice. > Usually, C code does have array length info; it's just not in a form that the language ties to the array itself. This is actually why C23 made VLA support semi-mandatory: it enables you to describe a function signature as int write_to_device(size_t len, char buf[len]) and C23 compilers are required to support that, even in absence of full VLA support! The intent of making this support mandatory was to be able to use that as a basis for adding better bounds-checking support to the language and compilers. (Although, as you noticed, there is an order-of-declarations issue compared to the typical idiomatic expression of such APIs in C, and the committee has yet to find a solution to that).
rcxdude 3y ago
In general I get the impression that embedded rust is fairly good for while(1) loop applications: the kind of thing you can do with arduino is also usually fairly easy to do in rust, modulo maybe not so good library support for random bits of hardware. What I generally see lacking is support for multitasking: the various HALs generally only support synchronous, usually only busy-loop blocking implementations, which is really limiting for a lot of embedded applications. This kind of thing is hard to get right, though. (in fact, while I like the theory of generic embedded HALs, I have yet to see a good implementation of the concept. Most effective HALs I have seen are specialised to one area or another, usually to one particular application)
Aurornis 3y ago
> 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). There are a lot of obscure MCU families out there. Most engineers or shops specialize in a couple, become familiar with those, and stick to it. Using and learning a brand new MCU family is a lot of work. As long as I can find Rust support for common MCUs that I use, I don’t care how broadly the rest of the market is covered.
- sitzkrieg 3y ago
  hope that mcu never goes on backorder :-)
  - petsfed 3y ago
    It would need to be an historic backorder to make me switch from e.g. STM32 to like a C2000. Or honestly from an STM32F to STM32H. For those how don't know, its very rare for a production device to use a socket for its MCU. Most MCUs don't even come in packages that support sockets. They're always soldered in. So unless you're switching to another MCU whose pinout, external clock, and power supply requirements are close enough that the hardware change is really just a BOM change, switching MCUs in case of a shortage is not a realistic option. Reportedly, some manufacturers were buying entire washing machines during the height of the chip shortage, just to de-solder the machines' MCUs and use them in their own products. That that is the better option should tell you how painful changing MCUs can be. And that's to say nothing about porting the firmware, which may, or may not, be trivial.
NoboruWataya 3y ago
> 1. https://arewertosyet.com/ https://arewertosyet.com/ to track rust RTOSes and their status As an aside, does anyone know if there is a central directory of these Rust "areweXyet" websites? I didn't know of this one but I knew about https://areweideyet.com/ https://areweideyet.com/ and https://areweguiyet.com/ https://areweguiyet.com/

by fusslo 3y ago

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.

jandrese 3y ago
The big problem is just the fundamental mismatch between what Rust requires and what you can do in C, especially with embedded code. If the library in question handles interrupts by jumping to an interrupt handler that updates some shared state you're going to have a bad time converting that into safe Rust.
Animats 3y ago
> C-to-Rust transpiler is a pretty doable project. It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics. An intelligent C to Rust translator would be a big win. You'd need to annotate the input C with info about how long arrays are and such, to guide the translator. It might be possible to use an LLM to analyze the code and provide annotations. Usually, C code does have array length info; it's just not in a form that the language ties to the array itself. If you see char* buf = malloc(len); the programmer knows that "buf" has length "len", but the programmer does not. Something needs to annotate "buf" with that info so that the translator knows it. Then the translator can generate Rust: let mut buf = vec![0;len]; The payoff comes at calls. C code: int write_to_device(char* buf, size_t len) is a common idiom. LLMs are good at idioms. At this point, one can guess that this is equivalent to fn write_to_device(buf: &[u8]) -> i32 in Rust. Then the translator has to track "len" to make sure that assert_eq!(buf.len(), len); is either provably true, or put in that assert to check it at run time. So that's a path to translation into safe Rust. Funding could probably be obtained from Homeland Security for this, given the new White House level interest in safe languages and the headaches being caused by the cyber war. Is CVS still down?
- jcranmer 3y ago
  > It's been done, but what comes out is terrible Rust. Everything is unsafe types with C semantics. The idea behind the current c2rust tool is that you'd do a one-shot conversion to Rust and then gradually do refactoring passes over the barely-Rust code to convert it to correct C code. The focus is on preserving semantics of C over writing anything close to idiomatic (cue a + b being translated to a.wrapping_add(b) all the time, e.g.). Which is an approach, but I'm not sure it ends up providing any value over "set your system to compile both C and Rust into a final image and then slowly move stuff from the C to the Rust side as appropriate" in practice. > Usually, C code does have array length info; it's just not in a form that the language ties to the array itself. This is actually why C23 made VLA support semi-mandatory: it enables you to describe a function signature as int write_to_device(size_t len, char buf[len]) and C23 compilers are required to support that, even in absence of full VLA support! The intent of making this support mandatory was to be able to use that as a basis for adding better bounds-checking support to the language and compilers. (Although, as you noticed, there is an order-of-declarations issue compared to the typical idiomatic expression of such APIs in C, and the committee has yet to find a solution to that).

rcxdude 3y ago

In general I get the impression that embedded rust is fairly good for while(1) loop applications: the kind of thing you can do with arduino is also usually fairly easy to do in rust, modulo maybe not so good library support for random bits of hardware. What I generally see lacking is support for multitasking: the various HALs generally only support synchronous, usually only busy-loop blocking implementations, which is really limiting for a lot of embedded applications. This kind of thing is hard to get right, though. (in fact, while I like the theory of generic embedded HALs, I have yet to see a good implementation of the concept. Most effective HALs I have seen are specialised to one area or another, usually to one particular application)

Aurornis 3y ago

> 3. "Out of 43 different MCU families, peripheral crates are currently available for only 16 (37%). There are a lot of obscure MCU families out there. Most engineers or shops specialize in a couple, become familiar with those, and stick to it. Using and learning a brand new MCU family is a lot of work. As long as I can find Rust support for common MCUs that I use, I don’t care how broadly the rest of the market is covered.

sitzkrieg 3y ago
hope that mcu never goes on backorder :-)
- petsfed 3y ago
  It would need to be an historic backorder to make me switch from e.g. STM32 to like a C2000. Or honestly from an STM32F to STM32H. For those how don't know, its very rare for a production device to use a socket for its MCU. Most MCUs don't even come in packages that support sockets. They're always soldered in. So unless you're switching to another MCU whose pinout, external clock, and power supply requirements are close enough that the hardware change is really just a BOM change, switching MCUs in case of a shortage is not a realistic option. Reportedly, some manufacturers were buying entire washing machines during the height of the chip shortage, just to de-solder the machines' MCUs and use them in their own products. That that is the better option should tell you how painful changing MCUs can be. And that's to say nothing about porting the firmware, which may, or may not, be trivial.

NoboruWataya 3y ago

> 1. https://arewertosyet.com/ https://arewertosyet.com/ to track rust RTOSes and their status As an aside, does anyone know if there is a central directory of these Rust "areweXyet" websites? I didn't know of this one but I knew about https://areweideyet.com/ https://areweideyet.com/ and https://areweguiyet.com/ https://areweguiyet.com/