I prefer Nim because it runs on every architecture where a C compiler is available. Also it's way more productive.
This Year in Embedded Rust
21–30 of 64 posts
Re: This Year in Embedded Rust
#22I would like to see that avr-unknown-gnu-atmega328 works with the latest compiler. Some bug in LLVM broke it[1], because it didn't work starting with versions after nightly-2021-01-07[2]. I know that rust team has nothing to do with this, but they should improve the gcc codegen[3] to be able to run rust on more embedded devices than LLVM has support for. Someone wanted to port his libc written in rust to ia64 and the gcc codegen broke and couldn't compile that.
[1] https://reviews.llvm.org/D114611
Re: This Year in Embedded Rust
#23Nice.
Re: This Year in Embedded Rust
#24Earlier quoted context omitted.
If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
> We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.
It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219
Re: This Year in Embedded Rust
#25Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…
> A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. Where does your limit go for that? I wrote a eurorack modular embedded thing on Teensy 4.0 (imxrt) in Rust this year. I just inspected the dep tree, it's 38 crates, with 1 being my own. https://gist.github.com/algesten/9617fc795f2fc94009f1ed311b1... It was a joy to write this in Rust, I look forward to my next proje…
How does cortex-m v0.6.7 manage to depend on cortex-m v0.7.3?
Re: This Year in Embedded Rust
#26Earlier quoted context omitted.
If that's your goal I think you should wait a few years before starting using Rust. We have already seen early Rust code not compiling with new compiler releases. Right now we are in a move fast and break things phase. Also, you need to be careful about what you implement yourself and what you import from crates. Otherwise it will be qt5 all over again.
> We have already seen early Rust code not compiling with new compiler releases. Are you talking about breaking changes in the compiler after Rust 1.0? That should be very rare, and generally easy to fix (e.g. by adding a few type annotations). Or did you use unstable features? (Not sure if embedded is usable without unstable nowadays)
It depends on your target architecture.
For example, embedded development on ARM with stable Rust has been possible since 2018 (Rust 1.31)
Re: This Year in Embedded Rust
#27Earlier quoted context omitted.
> We have already seen early Rust code not compiling with new compiler releases. I haven't really seen that happen with post-1.0 Rust, which is everything onwards of early 2015. I believe they've since tightened a couple of edge cases due to soundness issues, but nothing worse than that. Would be interesting to hear about your contrary experiences.
It happened in the lexical-core crate somewhere in 1.5X. Here is a bug report I got about it with compiler errors listed: https://github.com/cortex/ripasso/issues/219
This issue is on nightly Rust, not stable. A stable Rust compiler update should never break code.
See: https://doc.rust-lang.org/book/appendix-07-nightly-rust.html
Re: This Year in Embedded Rust
#28Earlier quoted context omitted.
> A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. Where does your limit go for that? I wrote a eurorack modular embedded thing on Teensy 4.0 (imxrt) in Rust this year. I just inspected the dep tree, it's 38 crates, with 1 being my own. https://gist.github.com/algesten/9617fc795f2fc94009f1ed311b1... It was a joy to write this in Rust, I look forward to my next proje…
How does cortex-m v0.6.7 manage to depend on cortex-m v0.7.3?
That's a way to avoid complicated coordinated upgrades across the ecosystem if certain conditions are met.
It's called the "semver-trick" [1].
Re: This Year in Embedded Rust
#29Earlier quoted context omitted.
Espressif (the makers of the hugely popular ESP32/ESP8266/... microcontrollers) hired an embedded Rust community member to work full time on Rust support for their chips: https://mabez.dev/blog/posts/esp-rust-espressif/
Does Espressif have large marketshare outside of hobbyists?
The ESP chips are in pretty much all cheap Chinese-made IoT and Smart Home devices.
Re: This Year in Embedded Rust
#30Two things have kept me away from embedded Rust before 1. A huge chain of dependencies. Security issues aside, I prefer my embedded code to be lean and clean. 2. A big departure from how things used to be done in this world. For example interrupt handlers almost look like AWS lambda code to me. Maybe that's the future, I don't know. But right now I am not comfortable with this way of doing low level coding. But I am…
Using Rust mods is exactly being lean and clean: would you rather take a bunch of include files, stupidly duplicates them in almost every translation units, and this would eventually blows up at some point of time, and is hard to reconfigure with some mysterious macro induced error, or, would you inter-depend on bunch of crates that might pull over 100mb of stuff at total that might have potential supply chain attack…
Explain the crate scanner thing? Ignoring security issues due to crates is no better than ignoring security issues due to memory errors or undefined behavior. And if you are doing safety critical code, where rust would shine, all those dependencies need to be certified to the same level as your own code. Sometimes re-creating and testing and certifying exactly the code you need is faster than reuse. Heresy I know, but it has been my experience with both embedded c++, and rust at work.
Edit: We have not deployed rust to safety critical yet, I am unaware of any certification that would allow that existing for any version of the rust compiler.