Announcing the Embedded Devices Working Group

announcements
#1

Hello Rustaceans!

Today I’m supper happy to officially announce the Embedded Devices Working Group!

As you may have read on this year roadmap Rust’s development will focus on 4 domains: Network services, WebAssembly, CLI apps and Embedded (bare metal) devices. Each domain has a Working Group (WG) dedicated to it. These WGs will work closely with the Rust teams and the community to make Rust – the language, its tooling, its documentation and its crate ecosystem – shine for these four domains.

I’m leading the embedded devices Working Group and I have put up a team of talented Rustaceans to help me make Rust awesome for embedded development:

On the team we have people to look over the ARM Cortex-M, AVR, MSP430 and RISCV ecosystems; people with professional experience in embedded development and embedded (e.g. HIL) testing; and people with experience in rustc and LLVM hacking.

We are using the rust-lang-nursery/embedded-wg repository to coordinate our work. Feel free to join the discussions! Let us know what you think is missing in the embedded Rust experience and what you think should be prioritized.

As result of our discussions we are creating work items, which you can help us with! There are only a few of them right now but we’ll be creating lots more as we go along and your help will play crucial role in the success of embedded Rust!

Let’s make this year a great one for embedded Rust! :fist:

81 Likes
Rust needs to run, and be easy to use, on every platform
#2

This is great! It would be awesome to see how this effort could be combined with our somewhat parallel efforts porting Tock to more platforms. On the one hand Tock has a particular model which may not be to the taste of some of the folks in the WG, but on the other there is a fair bit of infrastructure in Tock included a lot of not-otherwise-Rust users.

Would be good to try and avoid fragmenting the ecosystems to the extent possible.

5 Likes
#3

Although not strictly in embedded domain, would applications targeting UEFI environment also fall under this WG? Maybe a another way to put this question is, does this WG cover all no_std use cases?

3 Likes
#4

Awesome, this is definitely an interest area of mine.

I’m curious how you think something like SGX fits into the concept of “embedded”. On the one hand there are some similarities, but on the other, as Baidu’s rust-sgx-sdk has shown, thanks to the power of OCALLs you can gloss over SGX’s inability to (otherwise) make system calls by making them through OCALLs, to the point most of std can be made to work including networking and filesystem access.

1 Like
#5

Exciting news!

I am Jonathan from Pollen Robotics (ping @pierre-rouanet and @nicolas-rabault). Let me start to say thanks everyone, and especially Florian @skade, for welcoming us on the Rust stand in Embedded World last week!

Your vision for the embedded-wg is to improve the productivity of embedded software and the experience of programmers. I believe our work can make a fantastic practical use case for you.

Why? We are developing a modular kit for Robotics (see https://youtu.be/8aMwEfFqQUY?t=7s for the concept) that is developed in Rust and fully open source.

Our boards have the potential to become a great vector to spread Rust to embedded due to their built-in modularity. Each dev can work on a specific function/module for a driver of the week, and then it will be directly compatible with all the other modules, leveraging network effects. It also reduces the electronics knowledge needed, which represents a significant barrier to entry for some developers.

However using Rust has been a difficult ride at times for us:

  • For our boards, we use the stm32f0x2 because it is cheap, small and perfectly matches our application. To use Rust on it, we had to master the full stack in house, which is really heavy for a team of roboticists like us. We had to fork/modify the following repo:

    And then we built our application layers on top:

    Ideally teams like ours should not have to dig in or maintain the HAL level and have access to hal interfaces stabilized. If steps can be made in the next few weeks toward stabilizing basic hal features it would already be a big uncertainty relief. It would also help more people join Rust for embedded.

  • Most of our use cases ideally require to use interruption. However, to our knowledge, there is no official implementation yet in embedded-hal. How could we work together to propose an official interface for interrupts?

We plan to start our first sales online in May, and we would feel more confident if the HAL aspects become more stable and the stm32f0x2 is officially integrated within the working group. You could of course get early access to the boards if desired. This release will also be a good opportunity to communicate around an embedded product powered by Rust.

To summarize, if our use case is of interest and aligned with the embedded-wg vision, how could we work together?

We are a small startup with a tight budget but these aspects are so crucial for teams like us that we propose to financially support a few days of focused development on this front if it is of interest for members of the working group.

10 Likes
#6

Hi Jonathan,

thanks for posting your experience here. I think what you’re doing is really interesting, and I’m glad you’re so willing to open source your code and work with the rest of the embedded Rust ecosystem. I also think it’s especially exciting to see some commercial usage of Rust in this space.

I agree it’s unfortunate that any advanced user has to dig into these things right now. The ecosystem is slowly improving though, and as more use cases are covered, it will become less necessary to work on the lower layers of the stack to support one’s own use case.

I’ve opened an issue about interrupts in the embedded-hal repository. I suggest we discuss there.

Great to hear you’re so close to a commercial release! What do you mean by “officially integrated within the working group”?

I can’t speak for the whole working group, but I think your use case is of interest and definitely aligned with our vision.

For specific issues with the repositories you forked, the issue trackers of the respective repository are probably the best venue for cooperation. For anything else, just come over to the working group repository. Feel free to add your feedback to any issues, or open new ones as you see fit.

Thank you for being willing to invest into the ecosystem like that! I know we’ve already been talking via email, but if you’d like some more options, I suggest you create a post in the https://users.rust-lang.org/.

4 Likes
#7

Just posting my previous question again: does this WG also cover no_std scenarios beyond embedded such as UEFI applications?

1 Like
#8

I’m sorry that you haven’t received a reply yet. To my knowledge, we haven’t talked about UEFI in the working group, and I don’t think anything beyond embedded development with microcontrollers is a focus of the working group right now.

That said, other no_std use cases might benefit from our work indirectly. I don’t know anything about UEFI applications though, so I can’t say anything more conrete. Feel free to open an issue in the embedded-wg repository, if there’s anything that you think could be improved. You can also check out the open issues for ongoing discussions. Maybe there’s something in there that relates to UEFI applications that could use your input.

1 Like
#9

Thanks @hannobraun. I appreciate the current focus area.

I don’t think UEFI has any special needs beyond what’s needed for embedded. In fact it may need less than embedded, for UEFI’s almost a full OS itself. Like you said, much of the work this group does should benefit UEFI support directly. Things such as xargo merging into cargo, more stable compiler intrinsics etc.

Thank you for the reply.

1 Like
#10

Yes please! Here’s the issue for others to follow:

#11

I would like to make everyone here aware of the competition, at least wrt how most people will view it.

#12

Thanks for the info. I see that the project is very interesting.

Now, that made me think “What does ‘bare metal’ mean to us?”. They are using Linux Kernel but don’t have libc. Is it bare metal? What if with a real-time OS?

Would it be qualified to join this WG if I use some real-time OS with Rust? If so, please let me know! I’m going to use a real-time OS near future and I’m very interested in using Rust with it.

#13

Hi everybody! I am working for a custom OS based distribution/company, on the Linux kernel and Raspberry Pi. I also do a Summer of Code, on Redox; the Rust-based OS where I am porting the OS with the help of @microcolonel from ARM to the Aarch64.

I discovered about the group as they liked my post Porting Redox to Aarch64 on Twitter. The reason I am writing is that I would very happily want to contribute to the Embedded Devices project as I have quite some experience in the field; on the same time I am looking to learn and improve myself.

I hope that I can offer something in the project. Please let me know of some tasks I could dive into! Thank you :smile:

GitHub Bio

#14

You can contact members of the embedded working group on IRC. I’m sure they’d be happy for your help: https://github.com/rust-lang-nursery/embedded-wg#contact

Here are some help-wanted issues you could look over helping with: https://github.com/rust-lang-nursery/embedded-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahelp-wanted

2 Likes
#15

Hi there,

Same question as @bascule. I wonder if the rust-sgx project could participate in embedded-wg. Though it only works on x86_64 arch, it depends on a customized libsgx_tlibc and a series of SGX-platform specific libraries provided by Intel. It supports xargo with a new target x86_64-unknown-linux-sgx. The SGX hardware (so called MEE) is a part of latest Intel CPU. Don’t know whether or not it could be considered as ‘embedded’. Thanks!

Best, Yu

#16

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.