# Announcing the Embedded Devices Working Group **URL:** \ **Category:** announcements\ **Created:** [February 27, 2018, 4:10pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839 "2018-02-27T16:10:32Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![japaric](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/japaric/32/28_2.png) [@japaric](https://internals.rust-lang.org/u/japaric)\ **Post date:** [February 27, 2018, 4:10pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/1 "2018-02-27T16:10:32Z")
Hello Rustaceans! Today I’m supper happy to officially announce the Embedded Devices Working Group! As you may have read on [this year roadmap](https://github.com/rust-lang/rfcs/pull/2314) 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](https://internals.rust-lang.org/t/announcing-the-2018-domain-working-groups/6737) the embedded devices Working Group and I have put up a team of talented Rustaceans to help me make Rust awesome for embedded development: - dvc94ch (RISCV) - [GH](https://github.com/dvc94ch) - @dylanmckay (AVR) - [GH](https://github.com/dylanmckay) - @hannobraun - [GH](https://github.com/hannobraun) - @bitshiftmask - [GH](https://github.com/jamesmunns) - @japaric (lead) - [GH](https://github.com/japaric) - @jcsoo - [GH](https://github.com/jcsoo) - @pftbest (MSP430) - [GH](https://github.com/pftbest) - @thejpster - [GH](https://github.com/thejpster) 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](https://github.com/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](https://github.com/rust-lang-nursery/embedded-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahelp-wanted) 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! ✊ ---
**Author:** ![alevy](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/alevy/32/1657_2.png) [@alevy](https://internals.rust-lang.org/u/alevy)\ **Post date:** [February 27, 2018, 6:58pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/2 "2018-02-27T18:58:55Z")
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. ---
**Author:** ![gurry](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gurry/32/2972_2.png) [@gurry](https://internals.rust-lang.org/u/gurry)\ **Post date:** [March 1, 2018, 4:15am UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/3 "2018-03-01T04:15:06Z")
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? ---
**Author:** ![bascule](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/bascule/32/3057_2.png) [@bascule](https://internals.rust-lang.org/u/bascule)\ **Post date:** [March 1, 2018, 6:25am UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/4 "2018-03-01T06:25:54Z")
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. ---
**Author:** ![jgrizou](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/jgrizou/32/3685_2.png) [@jgrizou](https://internals.rust-lang.org/u/jgrizou)\ **Post date:** [March 5, 2018, 2:06pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/5 "2018-03-05T14:06:03Z")
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](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: - 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. ---
**Author:** ![hannobraun](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hannobraun/32/3555_2.png) [@hannobraun](https://internals.rust-lang.org/u/hannobraun)\ **Post date:** [March 7, 2018, 3:51pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/6 "2018-03-07T15:51:35Z")
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. > [@jgrizou](#): > > 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. 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. > [@jgrizou](#): > > 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? I've opened [an issue about interrupts](https://github.com/japaric/embedded-hal/issues/57) in the embedded-hal repository. I suggest we discuss there. > [@jgrizou](#): > > 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. Great to hear you're so close to a commercial release! What do you mean by "officially integrated within the working group"? > [@jgrizou](#): > > To summarize, if our use case is of interest and aligned with the embedded-wg vision, how could we work together? 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](https://github.com/rust-lang-nursery/embedded-wg). Feel free to add your feedback to any issues, or open new ones as you see fit. > [@jgrizou](#): > > 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. 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/](https://users.rust-lang.org/). ---
**Author:** ![gurry](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gurry/32/2972_2.png) [@gurry](https://internals.rust-lang.org/u/gurry)\ **Post date:** [March 8, 2018, 5:50am UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/7 "2018-03-08T05:50:54Z")
Just posting my previous question again: does this WG also cover `no_std` scenarios beyond embedded such as UEFI applications? ---
**Author:** ![hannobraun](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/hannobraun/32/3555_2.png) [@hannobraun](https://internals.rust-lang.org/u/hannobraun)\ **Post date:** [March 8, 2018, 2:01pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/8 "2018-03-08T14:01:52Z")
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](https://github.com/rust-lang-nursery/embedded-wg), 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. ---
**Author:** ![gurry](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/gurry/32/2972_2.png) [@gurry](https://internals.rust-lang.org/u/gurry)\ **Post date:** [March 9, 2018, 12:25am UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/9 "2018-03-09T00:25:49Z")
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. ---
**Author:** ![RandomInsano](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/randominsano/32/2097_2.png) [@RandomInsano](https://internals.rust-lang.org/u/RandomInsano)\ **Post date:** [March 11, 2018, 7:37pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/10 "2018-03-11T19:37:33Z")
> [@gurry](#): > > xargo merging into cargo Yes please! Here’s the issue for others to follow: > > > \# Summary > > This RFE proposes adding \[Xargo\]'s functionality of building a sysr…oot on the fly to Cargo as a nightly-only feature. > > \[Xargo\]: https://github.com/japaric/xargo > > \# Motivation > > Many (all?) no-std / embedded developers have to Install One More Tool because the ability to build core / std from source is missing in Cargo. Apart from the inconvenience, the Xargo wrapper is from for perfect: it can trigger unnecessary sysroot rebuilds because it doesn't replicate Cargo fingerprinting mechanism; it can sometimes fail to trigger a necessary sysroot rebuild (japaric/xargo#189); it doesn't track changes in the sysroot source code (japaric/xargo#139); and it doesn't understand the \`+nightly\` command line argument because it's not a rustup shim (japaric/xargo#123) among other deviations from the behavior users expect from a built-in Cargo subcommand. > > Apart from all the issues Xargo also ties no-std / embedded development to the nightly channel. This experiment will hopefully be a first step towards enabling no-std / embedded development on the stable channel. > > \# Implementation details > > \## User interface: \`\[sysroot\]\` > > A \`\[sysroot\]\` section will be added to Cargo configuration file: > > \`\`\` toml > \# .cargo/config > \[sysroot\] > rust-src = "~/.rustup/toolchains/nightly-x86\_64-unknown-linux-gnu/lib/rustlib/src/rust/src" > > \[sysroot.core\] > path = "libcore" # paths are relative to \`rust-src\` when not absolute > stage = 1 # see multi-stage builds section below > > \[sysroot.compiler\_builtins\] > git = "https://github.com/rust-lang-nursery/compiler-builtins" > features = \["mem"\] > stage = 2 > \`\`\` > > There the user can specify the crates that will be included in the sysroot. Only path and git dependencies are allowed. The \`\[sysroot.rust-src\]\` setting is a convenience that lets the user use relative paths. > > \## Behavior > > If a \`\[sysroot\]\` setting is found in Cargo configuration file: > > Cargo will (re)build the sysroot crates for the target and place the build artifacts in \`$TARGET\_DIR/sysroot/lib/rustlib/$TARGET\` \*before\* executing subcommands that involve invoking \`rustc\` or \`rustdoc\`. Then when invoking the actual subcommand Cargo will append the argument \`--sysroot=$TARGET\_DIR/sysroot\` to all its \`rustc\` and \`rustdoc\` invocations \*except\* the ones used to build build scripts (build.rs). > > The usual fingerprinting mechanism applies to the sysroot build: for example changes to \`\[profile\]\` in Cargo.toml and changes in the sysroot source code will trigger a sysroot rebuild. > > The sysroot crates will always be built using the \*release\* profile to not regress the performance and binary size of \*dev\* builds when switching to builds that use \`\[sysroot\]\`. > > \### Multi-stage builds > > There are crates in the \`std\` facade, like the \`test\` crate, that have implicit dependencies on other members of the facade. Building sysroots that include these crates require \*multi-stage builds\*. > > In multi-stage builds the sysroot will be build as follows: all the crates in the first stage are build against the default sysroot; then all the crates in the second stage are build using the stage 1 artifacts as a custom sysroot (i.e. \`--sysroot\` is passed to \`rustc\`); then all the crates in the third stage are build using the stage 1 and 2 artifacts as a custom sysroot; the process continues until all stages are built; finally the artifacts of all the stages are placed in \`$TARGET\_DIR/sysroot/lib/rustlib/$TARGET\`. > > \# Potential additions / tweaks > > Xargo doesn't require the user to specify a \`rust-src\` setting because it assumes that both \`rustup\` and the \`rust-src\` component are installed and it uses \`rustc --print sysroot\` to get the path to the Rust source. We could do the same here by either: (a) probing for the existence of \`rust-src\` and printing a helpful error message when it's not installed, or (b) committing to always ship \`rust-src\` with the toolchain. > > Xargo always rebuilds the sysroot in release mode but we could have the Cargo implementation use the dev profile when \`--release\` is not passed to the subcommand. > > \# Future steps > > Revisit rust-lang/rfcs#1133 to see if there's a desire for the changes proposed there that aren't included in this RFE: eliminating the concept of the sysroot, versioning the crates in the std facade, etc. > > \*\*UPDATE\*\*(2018-01-20): Don't pass \`--sysroot\` to \`rustc\` when building build scripts (build.rs). Those should be build against the default sysroot because they always run on the host. If the build scripts were to be build against the custom sysroot the sysroot would need to contain the \`rust-std\` artifacts of the host and that would require copying (or linking) those into \`$TARGET\_DIR/sysroot/lib/rustlib/$HOST\`, which is a waste of space. > > \--- > > cc @alexcrichton @nrc @Ericson2314 ---
**Author:** ![doubleagent](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/doubleagent/32/1875_2.png) [@doubleagent](https://internals.rust-lang.org/u/doubleagent)\ **Post date:** [March 26, 2018, 2:06pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/11 "2018-03-26T14:06:22Z")
I would like to make everyone here aware of [the competition](https://gokrazy.org/), at least wrt how most people will view it. ---
**Author:** ![yashi](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/yashi/32/3609_2.png) [@yashi](https://internals.rust-lang.org/u/yashi)\ **Post date:** [April 1, 2018, 2:45pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/12 "2018-04-01T14:45:10Z")
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. ---
**Author:** ![wizofe](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/wizofe/32/4540_2.png) [@wizofe](https://internals.rust-lang.org/u/wizofe)\ **Post date:** [August 6, 2018, 8:47pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/13 "2018-08-06T20:47:26Z")
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](https://github.com/raw-bin) from ARM to the Aarch64. I discovered about the group as they liked my post [Porting Redox to Aarch64](https://bit.ly/2Odgqmb) 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 😄 [GitHub](https://github.com/wizofe)[Bio](https://linkedin.com/in/wizofe) ---
**Author:** ![johnthagen](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/johnthagen/32/2005_2.png) [@johnthagen](https://internals.rust-lang.org/u/johnthagen)\ **Post date:** [August 6, 2018, 10:58pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/14 "2018-08-06T22:58:00Z")
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](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](https://github.com/rust-lang-nursery/embedded-wg/issues?q=is%3Aissue+is%3Aopen+label%3Ahelp-wanted) ---
**Author:** ![dingelish](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/dingelish/32/4561_2.png) [@dingelish](https://internals.rust-lang.org/u/dingelish)\ **Post date:** [August 13, 2018, 9:24pm UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/15 "2018-08-13T21:24:52Z")
Hi there, Same question as @bascule. I wonder if the [rust-sgx](https://github.com/baidu/rust-sgx-sdk) 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 ---
**Author:** ![system](https://sea2.discourse-cdn.com/flex002/user_avatar/internals.rust-lang.org/system/32/14092_2.png) [@system](https://internals.rust-lang.org/u/system)\ **Post date:** [March 25, 2019, 8:29am UTC](https://internals.rust-lang.org/t/announcing-the-embedded-devices-working-group/6839/16 "2019-03-25T08:29:42Z")
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.