Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 64 posts

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

#21

Post by supportlocal4h »

metalloid wrote: post #4
maneesh wrote: post #2

Our company builds a wearable device using an NRF5x chip, and our firmware is written in C. We are moving to Rust for our newest device, in order to run graphical output and RT operations. It is looking pretty sweet!

And why not Carbon? :-)

Sometimes it's hard to distinguish trolls from legitimate seekers of knowledge. I'd rather feed a troll than starve a student,

1. Carbon does not aim to replace C. It targets C++ devs. 2. Carbon is still just an idea. Well, more than an idea, but less than ready. 3. Carbon is meant for people who cannot move to something like Rust. They don't intend to compete in enviroments that have modern options.

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

#22

Post by quake »

garphunkle wrote: post #9

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…

I've found Cargo more than up to the task of managing build configurations, and doesn't require monkeying around with CMake scripts or Makefiles. It was pointed out in another comment but you can gate features and crates based on the target you're compiling to. Cargo also supports custom build profiles so you can also pick and choose what you want even if it's all on the same target.

Creating a heap in Rust on a cortex M is safe and cheap-ish with a crate supported by the rust-lang developers. Much easier than implementing your own free() method on a memory pool.

I think you would like rtic. Not a pre-emptive rtos, but a way to manage context between ISR's without relying on some kind of module or global variable that can get corrupted by multiple accessors. Very minimal overhead compared to FreeRTOS

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

#23

Post by larve »

ctrlmeta wrote: post #12
garphunkle wrote: post #9

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…

> (easy to do if you never, ever malloc) Not an embedded systems developer so an honest question. What do you do instead of malloc? Have a large array on stack and manage memory within that manually?

I mostly allocate static areas in the BSS segment. That way, I know at compile time that I allocated my memory correctly, assuming that I have my stack under control.

Then I follow my two rules of embedded development: - no recursion - everything has to be O(1)

If I'm honest, I can't remember a project where I had to use even a pool allocator, which you would usually need if you were trying to do like, reorderable queues / lists / trees or so. I right now can't come up with a proper use case. If you do need to say, compute a variable length sequence of actions based on an incoming packet, then I would structure my code so that:

a) only the current action and the next action get computed (so that there is no pause in between executing them)

b) compute the next action when I switch over (basically with a ping-pong buffer)

c) verify real-time invariants

My most used structure is the ring buffer to smooth out "semi-realtime" stuff, and if the ring buffer overflows, well, the ring buffer overflows and it has to be dealt with. If I could have more memory I would just make the ring buffer bigger.

I'm not sure how clear this explanation is :)

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

#24

Post by adolph »

I’ve been super curious about both Rust and ESP. It seems like Espressif is interested enough to commission a Rust dev board (ESP32-C3-DevKit-RUST-1) and training using it.

https://github.com/esp-rs/esp-rust-board/

https://github.com/ferrous-systems/espressif-trainings

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

#26

Post by AlbertoGP »

I took a look and realized that I wasn’t yet ready for it.

Last year a recruiter contacted me about assisting Volkswagen transition from C++ to Rust for their CARIAD embedded automotive platform.

My experience with Rust is only on application development, not embedded systems, but the job sounded quite interesting and I took a look at Embedded Rust. After discussing it a bit with them, my response to them was to recommend going with someone else, because the way Rust is used in that domain amounts to almost a different language and my experience was not adequate. I said that what they needed was someone that had battled with those arcane details already, not a Rust generalist.

I do think Rust would be good for such systems, but that at the moment it’s weighted down by architecture astronautics.

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

#27

Post by flyingfences »

ctrlmeta wrote: post #12
garphunkle wrote: post #9

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…

> (easy to do if you never, ever malloc) Not an embedded systems developer so an honest question. What do you do instead of malloc? Have a large array on stack and manage memory within that manually?

Function variables, with scope and lifetime limited to the call, get their place on the stack as usual. Everything else -- i.e., constants, static function variables, and anything with higher scope -- is allocated its own memory at compile time. We have no heap. We use no variable-length arrays or other, more dynamic data structures. Anything that needs to grow and shrink does so within its own fixed-length buffer.

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

#28

Post by ctrlmeta »

larve wrote: post #23
ctrlmeta wrote: post #12

Earlier quoted context omitted.

> (easy to do if you never, ever malloc) Not an embedded systems developer so an honest question. What do you do instead of malloc? Have a large array on stack and manage memory within that manually?

I mostly allocate static areas in the BSS segment. That way, I know at compile time that I allocated my memory correctly, assuming that I have my stack under control. Then I follow my two rules of embedded development: - no recursion - everything has to be O(1) If I'm honest, I can't remember a project where I had to use even a pool allocator, which you would usually need if you were trying to do like, reorderable qu…

> I mostly allocate static areas in the BSS segment.

How is this done from C code? Any code examples someone can point me to?

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

#29

Post by detuks »

adolph wrote: post #24

I’ve been super curious about both Rust and ESP. It seems like Espressif is interested enough to commission a Rust dev board (ESP32-C3-DevKit-RUST-1) and training using it. https://github.com/esp-rs/esp-rust-board/ https://github.com/ferrous-systems/espressif-trainings

That is what I felt as well. Managed to create simple project where MCU connects to WiFi, announces itself on network (mDNS) and gives me a tcp api to turn led on and off. I used ESP32-S3.

Ability to use STD and their rust creates made it very easy to do.

Tho most of their rust creates are just wrappers around C.

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

#30

Post by jsmith45 »

quake wrote: post #18

I've done some small embedded Rust applications on various STM32 and RP2040 boards. I've been doing embedded dev in C professionally for 7 years and Rust full-time for 2.5, mix or system and bare metal. It's very hard to unlatch your brain from some of the common C/C++ embedded principles of static context variables and thinking of the hardware registers as "owned" memory, which you have to do in Rust. The auto-gener…

Ouch. Making you treat hardware registers as owned (or use unsafe to access them) feels like it would be unpleasant if writing single threaded firmware, where the only preemption is the interrupt handler.

I’d much rather have them exposed as some form of atomic that is restricted to operations that are atomic on this specific hardware.

Post reply on HN