Live data from Hacker News

Ask HN: Has any Rust developer moved to embedded device programming?

news.ycombinator.com

61–64 of 64 posts

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#61

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

Is rust interoperable with C and ASM? I would think it'd have to be. Some of those things (all of them?) are considerations the system designer needs to worry about regardless.

It seems like you should be able to still use most of the stuff provided by the toolchain in a similar fashion. That said, trying to do a native implementation by porting the code, or just using a C/ASM bootloader could prove tricky for newcomers.

Bootloaders are often black boxes. It could be flashing something written in COBAL, and it would be none the wiser. It seems like rust would need to provide a mechanism for entry pointing. I don't know how to handle memory mapping and linker scripting in rust.

I'm not disagreeing that it could be a huge barrier, but theoretically it doesn't have to be that much, or at least most of it is stuff you'll often be dealing with anyway.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#62
We rebuilt solo v2 [1] firmware in rust, compared to v1 in C [2]. I haven't written any rust code so take what I say with a grain of salt, but generally speaking I think our experience has been very positive.

Rust forced us to structure the code a bit better, that makes it easier for multiple people to collaborate on it. Slightly harder learning curve, but that wasn't an issue in our case.

In the history of solo, we had a couple security bugs that rust would probably have prevented, so this is a plus for the language. Moreover, the cryptography community is pretty active and we can leverage solid + well maintained libraries.

One downside has been collaboration with other OS projects. When we had the C firmware and fido2 library, in less than 1 year we've got 3 other products embedding our code and also a couple manufacturers making demos with it -- a great win. With rust to my knowledge we're not there yet, but of course we're very positive.

[1] https://github.com/solokeys/solo2

[2] https://github.com/solokeys/solo1

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#63

I've been working in embedded for 5 years and am curious how rust could solve my biggest headaches: * Managing build configurations - I use CMake to build a single application for multiple hardware platforms. This is accomplished almost exclusively through linking, e.g., a single header file "ble-ncp-driver.h" with multiple "ble-ncp-driver.cpp" files for each target platform. I call this the "fat driver" approach whi…

For configurations, rust supports features. To me they look very similar to ifdefs in C, except they're managed directly by cargo and can be passed down into dependencies and modules.

You can decide how to use them, for example you can very much create "fat drivers".

If you want to see an example, here's how we build for dev vs release, on two different boards. Cargo makes it really smooth. https://github.com/solokeys/solo2/blob/main/runners/lpc55/Ma...

Similarly, for testing, one annoyance for us is that in theory the user should press a button for every action. We have a feature to disable that, just so we can run integration tests (either on PC or on device) more smoothly.

Re: Ask HN: Has any Rust developer moved to embedded device programming?

#64
post #42

I'm fortunate enough to have just landed on a new team working with embedded Rust. Here are some of my takes, in no particular order. The language and ecosystem have come a long way in a very short time. It's easy to use safe `no_std` Rust on the stable toolchain for 98% of your code, and there are crates available for all kinds of things like memory management, register access, or even async runtimes. Compared with…

so what you are saying, is that rust solves the issue of finding competent engineers. you can use a language like rust such that engineers don’t need to be any good. it reminds me of microsoft frontpage and all the other scripting languages and tools that have been created to solve this issue. but here we are in 2022 and nothing has changed. people still hand code css and html to get what they want. embedded software…

One of the dumbest posts I've ever read on here.
Post reply on HN