From b263c4bc5599558db5da40b590f0719c8d53a510 Mon Sep 17 00:00:00 2001 From: James Munns Date: Thu, 29 Mar 2018 12:26:19 +0200 Subject: [PATCH 1/6] Initial commit of the second newsletter. Still some TODOs for @japaric --- newsletters/2018-03-29.md | 82 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 newsletters/2018-03-29.md diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md new file mode 100644 index 00000000..23486bb8 --- /dev/null +++ b/newsletters/2018-03-29.md @@ -0,0 +1,82 @@ +# The Embedded Working Group Newsletter - 2 + +> 2018-03-29 + +This is the second bi-weekly newsletter of the [Embedded WG] where we highlight new progress, celebrate cool projects, thank the community, and advertise projects that need help! + +If you want to mention something in [the next newsletter], make sure to leave a comment on the issue. + +[the next newsletter]: https://github.com/rust-lang-nursery/embedded-wg/issues/72 +[Embedded WG]: https://github.com/rust-lang-nursery/embedded-wg + +## Highlights + +> TODO: More specific stuff from Rust All Hands? + +* [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018! +* [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier +* [emilgardis] and [ryankurte] are busy [refactoring] the [svd-parser] crate + +[japaric]: https://github.com/japaric +[hannobraun]: https://github.com/hannobraun +[jamesmunns]: https://github.com/jamesmunns +[mock embedded-hal]: https://github.com/rust-lang-nursery/embedded-wg/issues/70 +[stable embedded rust development]: https://github.com/rust-lang-nursery/embedded-wg/issues/42 +[refactoring]: https://github.com/japaric/svd/issues/46 +[svd-parser]: https://github.com/japaric/svd +[ryankurte]: https://github.com/ryankurte +[emilgardis]: https://github.com/Emilgardis + +## Embedded Projects + +If you have an embedded project or blog post you would like to have featured in the Embedded WG Newsletter, make sure to mention it on the tracking issue for [the next newsletter], we would love to show it off! + +### `embedded-hal` drivers + +This is a list of recently released drivers that are part of the [Weekly Driver Initiative]. There are currently 5 Released Drivers, 14 WIP Drivers, and lots of TODOs! + +* [danielgallagher0] has released their [hts221] humidity and temperature sensor driver +* [MrBuddyCasino] has released their I2C based [mcp9808] temperature sensor driver +* [Ilya Epifanov] has released their I2C based [si5351] CMOS clock generator driver, check out the [si5351 docs] for more info +* [Edwin Amsler] is working on their [axp209] PMIC driver +* [dbrgn] is working on their Sensirion [sgp30] low-power gas sensor driver +* [pcein] has started work on their [pcd8544] for SPI based LCD controllers used in displays like the Nokia 5110 +* [nordmoen] is working on their driver for the [hc-sr04] ultrasonic distance sensor + +[Weekly Driver Initiative]: https://github.com/rust-lang-nursery/embedded-wg/issues/39 +[danielgallagher0]: https://github.com/danielgallagher0 +[hts221]: https://medium.com/@pdanielgallagher/hts221-humidity-and-temperature-sensor-88056ea9e5fa +[MrBuddyCasino]: https://github.com/MrBuddyCasino +[mcp9808]: https://crates.io/crates/mcp9808 +[Ilya Epifanov]: https://github.com/ilya-epifanov +[si5351]: https://github.com/ilya-epifanov/si5351 +[si5351 docs]: https://docs.rs/si5351/0.1.5/si5351/ +[Edwin Amsler]: https://github.com/RandomInsano +[axp209]: https://github.com/RandomInsano/axp209-rs +[pcein]: https://github.com/pcein +[pcd8544]: https://github.com/pcein/pcd8544 +[dbrgn]: https://github.com/dbrgn +[sgp30]: https://github.com/dbrgn/sgp30-rs +[nordmoen]: https://github.com/nordmoen +[hc-sr04]: https://github.com/nordmoen/hc-sr04 + +### `embedded-hal` Board/Chip Support Crates + +* [DoumanAsh] has started work on their [stm32l4x6-hal] chip support crate + +[DoumanAsh]: https://github.com/DoumanAsh +[stm32l4x6-hal]: https://github.com/DoumanAsh/stm32l4x6_hal + +## Thanks + +> TODO: Thank some people from the other rust teams, like @nagisa, +> @oli-obk, and ??? + +## Help Wanted + +* [Simon Sapin] posted some working code for the [DS3234] SPI RTC, and is looking for someone to turn it into a maintained crate! + +[Simon Sapin]: https://github.com/SimonSapin +[DS3234]: https://github.com/rust-lang-nursery/embedded-wg/issues/39#issuecomment-375262785 + +If you have an embedded project that could use contributors or maintainers, leave a comment for [the next newsletter]! From b990dbf083a65f06a159e8f2d11ef9415ec04cbe Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Thu, 29 Mar 2018 15:30:28 +0200 Subject: [PATCH 2/6] add summary of Rust All Hands --- newsletters/2018-03-29.md | 182 +++++++++++++++++++++++++++++++++++++- 1 file changed, 181 insertions(+), 1 deletion(-) diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md index 23486bb8..b0421bb9 100644 --- a/newsletters/2018-03-29.md +++ b/newsletters/2018-03-29.md @@ -10,8 +10,188 @@ If you want to mention something in [the next newsletter], make sure to leave a [Embedded WG]: https://github.com/rust-lang-nursery/embedded-wg ## Highlights +## The embedded WG at Rust All Hands + +This week ~15 Rust teams / working groups met for the Rust All Hands event. Some members of the +embedded WG were present and we had a chance to talk to the compiler, core and infra teams. These +are the highlights of our talks: + +### Embedded Rust on stable + +We had previously identified 3 unstable features / issues that tie embedded development to the +nightly channel in https://github.com/japaric/stable-embedded-rust . We talk to the other Rust teams +about the possibility of addressing these issues in time for the 2018 edition release and the +conclusion was that they thought that the timeline was possible. These are the 3 unstable features +we are referring to: + +- ~Xargo~ + +We'll ship a rust-std component (pre-compiled core+compiler-builtins) for the thumb* and msp430 + targets. This removes the need for Xargo so people will be able to do, for example, `rustup target + add thumb7m-none-eabi; cargo build --target thumbv7m-none-eabi` to cross compile to ARM Cortex-M. + +Tracking issue: [rust-lang/rust#49382]. + +[rust-lang/rust#49382]: https://github.com/rust-lang/rust/issues/49382 + +- `compiler-builtins` + +`extern crate compiler_builtins` is unstable to directly use. The fix we have decided on is to +inject that as part of the prelude you get from `#![no_std]`. + +So, today `#![no_std]` expands to something like this: + +``` rust +#![no_std] +extern crate core; +``` + +With our change the expansion will run like this: + +``` rust +#![no_std] +extern crate core; +extern crate compiler_builtins; // but this doesn't #![feature(compiler_builtins_lib)] +``` + +In the future we might want to merge `compiler-builtins` into `core` but that requires more effort +and can still be done if we do the `#![no_std]` prelude approach right now. + +Tracking issue: [rust-lang/rust#49380] + +[rust-lang/rust#49380]: https://github.com/rust-lang/rust/issues/49380 + +- `panic_fmt` + +There's an accepted RFC (#2070) for a stable mechanism to select the behavior of `panic!` in +`no_std` context, and there's a know issue where the arguments of `panic_fmt` are kept in the binary +even when they are unused by the `panic_fmt` implementation (cf. [rust-lang/embedded-wg#41]). + +[rust-lang/embedded-wg#41]: https://github.com/rust-lang-nursery/embedded-wg/issues/41 + +The main concern here was whether we'll be able to fix the binary size problem with the accepted +design or if we'll need some new design. The compiler team thinks that this can be fixed with the +existing design using MIR only rlibs but it's unlikely this will get fixed in time for the edition +release. @nagisa will likely propose an alternate solution that involves having Cargo select the +panic provider crate. + +### Non critical unstable features + +There are some other unstable features that although don't prevent you from doing embedded +development they come up often when doing no-std development. We had a chat with people on the +compiler team about them. + +- `const fn` + +This feature has been proposed for stabilization (cf. [rust-lang/rust#24111]). + +[rust-lang/rust#24111]: https://github.com/rust-lang/rust/issues/24111#issuecomment-376649804 + +- `asm!` + +Background: Some assembly operations can be implemented as external assembly files that are then +called into using FFI; other ops though do need to be inlined into the function from which they are +called to prevent losing semantics. Using external assembly file can be done on the stable channel. +The second type of operation requires the unstable `asm!` macro. + +The compiler team is not 100% sure on whether they want to stabilize inline assembly for the edition +release. The embedded WG has proposed an alternative proposal: expose *some* assembly operations +that need to be inlined as "Rust intrinsics" -- in a similar fashion to how SIMD is being +implemented; these intrinsics would be in the `core::asm::$ARCH` module and they could either be +implemented by lowering to a LLVM intrinsics or using inline assembly. For example: + +``` rust +pub mod asm { + pub mod arm { + #[inline(always)] + pub fn cpsid() { + unsafe { + asm!("cpsid i" ::: "memory" : "volatile"); + } + } + } +} +``` + +These would be stable APIs with an unstable implementation. If LLVM assembler syntax the +implementations of these functions would have to be updated. + +The embedded WG will submit an RFC proposing the `asm` module and that will include a list of +assembly operations that (a) are common and (b) need to be inlined for different architectures. + +- `#[used]` + +This experimental feature has been in the compiler for a while and it's required in some scenarios +when using LTO to prevent the compiler some function / `static` that needs to be in the final +binary. + +We'll try to get it stabilized by the edition release but it's not a high priority feature. + +### Stability of the embedded targets + +We don't only want to make embedded Rust possible on stable; we also want to make sure the embedded +targets don't regress. So we are going to add tests to rust-lang/rust CI to make sure regression +block PRs from landing. + +That effectively will make some of the embedded targets into the tier 1 platform. The core team is +fine with adding the thumb* targets (ARM Cortex-M) to tier 1; less maintained, still in +development and not fully mature targets like AVR, MSP430 and RISCV will become tier 3 -- they'll be +tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will +be binaries available for all nightly / beta / stable releases. + +We'll open an issue to discuss with the infra team the exact tests we want to add and track progress +on that, but have already told them about the kind of tests we want to add and they thought those +kind of tests are possible to implement. The kind of tests we discussed were: + +- It compiles and links +- Runs the cross compiled binary in QEMU doesn't crash and exits with exit code 0. +- Tracking the binary size of a program compiled with `-Os` / `-Oz` and notify someone or fail the + build if the size regresses by 5% / 10% or something. + +### LLVM backends that are not yet in rustc + +There are two embedded LLVM backends that have not yet been enabled in rustc for different reasons: +AVR and RISCV. + +In the case of AVR the main reason is that some LLVM codegen bugs prevent you from building core for +AVR. These bugs are related to 128-bit integers and formatting floats. The libs team discussed this +some time ago and they decided they are fine with landing arch specific `#[cfg]` attributes to +remove 128-bit integers and other things like float APIs. + +In the case of RISCV the LLVM backend is currently under active development and our current version +of LLVM doesn't fully support RISCV. We would have to backport several patches to make RISCV work on +our LLVM version. The core team feels OK with backporting those patches as long as they have already +landed in upstream LLVM, and are not still under review. + +### Tooling + +Getting tooling for e.g. binary inspection (e.g. `objdump`) can be hard on some platforms (e.g. +Windows) specially for architecture which currently are not too widely used (e.g. RISCV). We can +improve the situation here by shipping llvm tools with the Rust toolchain -- with one set of those +tools you can inspect all the architectures that Rust supports. These are the thoughts of the core / +infra team regarding this: + +- We put these tools in the sysroot and have them always shipped with the Rust toolchain so no + `rustup component add` required -- this is already the case with `lld`. It might not be possible + to provide these tools on all platforms but it's very likely they'll be available on tier 1 + platforms. + +- We do *not* add these tools to the user `$PATH`. Instead some Cargo subcommand will be created by + the embedded WG (e.g. `cargo objdump`) and that subcommand will look for `llvm-objdump` in the + sysroot and do the right thing. + +- We make no guarantees about the semantics and interface of these tools being preserved over time + (e.g. CLI changes, user facing output format changes, etc.). + +### The embedded Rust book + +We decided on an initial audience for the embedded book; we will be targeting people that know some +embedded stuff *and* some Rust. The main reason for this is that if someone knows one and not the +other then they can go and read existing Rust documentation or the Discovery book and then read the +embedded book. For more details check [rust-lang-nursery/embedded-wg#56]. + +[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56 -> TODO: More specific stuff from Rust All Hands? * [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018! * [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier From b3ad80b6b55d6642054d3997dc780a4da60d21dd Mon Sep 17 00:00:00 2001 From: James Munns Date: Thu, 29 Mar 2018 16:51:28 +0200 Subject: [PATCH 3/6] Initial formatting pass of the All Hands Special Feature --- newsletters/2018-03-29.md | 294 ++++++++++++++++---------------------- 1 file changed, 123 insertions(+), 171 deletions(-) diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md index b0421bb9..64c1327d 100644 --- a/newsletters/2018-03-29.md +++ b/newsletters/2018-03-29.md @@ -10,34 +10,101 @@ If you want to mention something in [the next newsletter], make sure to leave a [Embedded WG]: https://github.com/rust-lang-nursery/embedded-wg ## Highlights -## The embedded WG at Rust All Hands -This week ~15 Rust teams / working groups met for the Rust All Hands event. Some members of the -embedded WG were present and we had a chance to talk to the compiler, core and infra teams. These -are the highlights of our talks: +* [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier +* [emilgardis] and [ryankurte] are busy [refactoring] the [svd-parser] crate +* [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018. See the bottom of this post for more details! + +[japaric]: https://github.com/japaric +[hannobraun]: https://github.com/hannobraun +[jamesmunns]: https://github.com/jamesmunns +[mock embedded-hal]: https://github.com/rust-lang-nursery/embedded-wg/issues/70 +[stable embedded rust development]: https://github.com/rust-lang-nursery/embedded-wg/issues/42 +[refactoring]: https://github.com/japaric/svd/issues/46 +[svd-parser]: https://github.com/japaric/svd +[ryankurte]: https://github.com/ryankurte +[emilgardis]: https://github.com/Emilgardis + +## Embedded Projects + +If you have an embedded project or blog post you would like to have featured in the Embedded WG Newsletter, make sure to mention it on the tracking issue for [the next newsletter], we would love to show it off! + +### `embedded-hal` drivers + +This is a list of recently released drivers that are part of the [Weekly Driver Initiative]. There are currently 5 Released Drivers, 14 WIP Drivers, and lots of TODOs! + +* [danielgallagher0] has released their [hts221] humidity and temperature sensor driver +* [MrBuddyCasino] has released their I2C based [mcp9808] temperature sensor driver +* [Ilya Epifanov] has released their I2C based [si5351] CMOS clock generator driver, check out the [si5351 docs] for more info +* [Edwin Amsler] is working on their [axp209] PMIC driver +* [dbrgn] is working on their Sensirion [sgp30] low-power gas sensor driver +* [pcein] has started work on their [pcd8544] for SPI based LCD controllers used in displays like the Nokia 5110 +* [nordmoen] is working on their driver for the [hc-sr04] ultrasonic distance sensor + +[Weekly Driver Initiative]: https://github.com/rust-lang-nursery/embedded-wg/issues/39 +[danielgallagher0]: https://github.com/danielgallagher0 +[hts221]: https://medium.com/@pdanielgallagher/hts221-humidity-and-temperature-sensor-88056ea9e5fa +[MrBuddyCasino]: https://github.com/MrBuddyCasino +[mcp9808]: https://crates.io/crates/mcp9808 +[Ilya Epifanov]: https://github.com/ilya-epifanov +[si5351]: https://github.com/ilya-epifanov/si5351 +[si5351 docs]: https://docs.rs/si5351/0.1.5/si5351/ +[Edwin Amsler]: https://github.com/RandomInsano +[axp209]: https://github.com/RandomInsano/axp209-rs +[pcein]: https://github.com/pcein +[pcd8544]: https://github.com/pcein/pcd8544 +[dbrgn]: https://github.com/dbrgn +[sgp30]: https://github.com/dbrgn/sgp30-rs +[nordmoen]: https://github.com/nordmoen +[hc-sr04]: https://github.com/nordmoen/hc-sr04 + +### `embedded-hal` Board/Chip Support Crates + +* [DoumanAsh] has started work on their [stm32l4x6-hal] chip support crate + +[DoumanAsh]: https://github.com/DoumanAsh +[stm32l4x6-hal]: https://github.com/DoumanAsh/stm32l4x6_hal + +## Thanks -### Embedded Rust on stable +> TODO: Thank some people from the other rust teams, like @nagisa, +> @oli-obk, and ??? + +## Help Wanted + +* [Simon Sapin] posted some working code for the [DS3234] SPI RTC, and is looking for someone to turn it into a maintained crate! + +[Simon Sapin]: https://github.com/SimonSapin +[DS3234]: https://github.com/rust-lang-nursery/embedded-wg/issues/39#issuecomment-375262785 -We had previously identified 3 unstable features / issues that tie embedded development to the -nightly channel in https://github.com/japaric/stable-embedded-rust . We talk to the other Rust teams -about the possibility of addressing these issues in time for the 2018 edition release and the -conclusion was that they thought that the timeline was possible. These are the 3 unstable features -we are referring to: +If you have an embedded project that could use contributors or maintainers, leave a comment for [the next newsletter]! + +# Special Feature: The Embedded WG at the 2018 Rust All Hands + +This week 15 or so Rust teams/working groups met for the Rust All Hands event in Berlin. Some members of the embedded WG were present and we had a chance to talk to the compiler, core and infra teams. + +These are the highlights of our talks. + +## Embedded Rust on stable -- ~Xargo~ +We had previously identified 3 unstable features / issues that tie embedded development to the nightly channel in https://github.com/japaric/stable-embedded-rust. We talked to the other Rust teams about the possibility of addressing these issues in time for the 2018 edition release and the conclusion was that they thought that the timeline was possible. These are the 3 unstable features we are referring to: -We'll ship a rust-std component (pre-compiled core+compiler-builtins) for the thumb* and msp430 - targets. This removes the need for Xargo so people will be able to do, for example, `rustup target - add thumb7m-none-eabi; cargo build --target thumbv7m-none-eabi` to cross compile to ARM Cortex-M. +### Unstable Feature #1: `xargo` -Tracking issue: [rust-lang/rust#49382]. +We'll ship a rust-std component (pre-compiled `core`+`compiler-builtins`) for the `thumb*` and `msp430` targets. This removes the need for `xargo` so people will be able to do something like the following to cross compile to ARM Cortex-M: + +```bash +rustup target add thumb7m-none-eabi +cargo build --target thumbv7m-none-eabi +``` + +**Tracking issue**: [rust-lang/rust#49382]. [rust-lang/rust#49382]: https://github.com/rust-lang/rust/issues/49382 -- `compiler-builtins` +### Unstable Feature #2: `compiler-builtins` -`extern crate compiler_builtins` is unstable to directly use. The fix we have decided on is to -inject that as part of the prelude you get from `#![no_std]`. +`extern crate compiler_builtins` is unstable to directly use. The fix we have decided on is to inject that as part of the prelude you get from `#![no_std]`. So, today `#![no_std]` expands to something like this: @@ -51,54 +118,42 @@ With our change the expansion will run like this: ``` rust #![no_std] extern crate core; -extern crate compiler_builtins; // but this doesn't #![feature(compiler_builtins_lib)] + +// but this doesn't #![feature(compiler_builtins_lib)] +extern crate compiler_builtins; ``` -In the future we might want to merge `compiler-builtins` into `core` but that requires more effort -and can still be done if we do the `#![no_std]` prelude approach right now. +In the future we might want to merge `compiler-builtins` into `core` but that requires more effort and can still be done if we do the `#![no_std]` prelude approach right now. -Tracking issue: [rust-lang/rust#49380] +**Tracking issue:** [rust-lang/rust#49380] [rust-lang/rust#49380]: https://github.com/rust-lang/rust/issues/49380 -- `panic_fmt` +### Unstable Feature #3: `panic_fmt` -There's an accepted RFC (#2070) for a stable mechanism to select the behavior of `panic!` in -`no_std` context, and there's a know issue where the arguments of `panic_fmt` are kept in the binary -even when they are unused by the `panic_fmt` implementation (cf. [rust-lang/embedded-wg#41]). +There's an accepted RFC (#2070) for a stable mechanism to select the behavior of `panic!` in `no_std` context, and there's a know issue where the arguments of `panic_fmt` are kept in the binary even when they are unused by the `panic_fmt` implementation (cf. [rust-lang/embedded-wg#41]). [rust-lang/embedded-wg#41]: https://github.com/rust-lang-nursery/embedded-wg/issues/41 -The main concern here was whether we'll be able to fix the binary size problem with the accepted -design or if we'll need some new design. The compiler team thinks that this can be fixed with the -existing design using MIR only rlibs but it's unlikely this will get fixed in time for the edition -release. @nagisa will likely propose an alternate solution that involves having Cargo select the -panic provider crate. +The main concern here was whether we'll be able to fix the binary size problem with the accepted design or if we'll need some new design. The compiler team thinks that this can be fixed with the existing design using MIR only rlibs but it's unlikely this will get fixed in time for the edition release. [nagisa] will likely propose an alternate solution that involves having Cargo select the panic provider crate. -### Non critical unstable features +[nagisa]: https://github.com/nagisa -There are some other unstable features that although don't prevent you from doing embedded -development they come up often when doing no-std development. We had a chat with people on the -compiler team about them. +## Non critical unstable features -- `const fn` +There are some other unstable features that don't prevent you from doing embedded development, however they come up often when doing no-std development. We had a chat with people on the compiler team about them. + +### Unstable Feature #4: `const fn` This feature has been proposed for stabilization (cf. [rust-lang/rust#24111]). [rust-lang/rust#24111]: https://github.com/rust-lang/rust/issues/24111#issuecomment-376649804 -- `asm!` +### Unstable Feature #5: `asm!` -Background: Some assembly operations can be implemented as external assembly files that are then -called into using FFI; other ops though do need to be inlined into the function from which they are -called to prevent losing semantics. Using external assembly file can be done on the stable channel. -The second type of operation requires the unstable `asm!` macro. +**Background**: Some assembly operations can be implemented as external assembly files that are then called into using FFI; other ops though do need to be inlined into the function from which they are called to prevent losing semantics. Using external assembly file can be done on the stable channel. The second type of operation requires the unstable `asm!` macro. -The compiler team is not 100% sure on whether they want to stabilize inline assembly for the edition -release. The embedded WG has proposed an alternative proposal: expose *some* assembly operations -that need to be inlined as "Rust intrinsics" -- in a similar fashion to how SIMD is being -implemented; these intrinsics would be in the `core::asm::$ARCH` module and they could either be -implemented by lowering to a LLVM intrinsics or using inline assembly. For example: +The compiler team is not 100% sure on whether they want to stabilize inline assembly for the edition release. The embedded WG has proposed an alternative proposal: expose *some* assembly operations that need to be inlined as "Rust intrinsics" -- in a similar fashion to how SIMD is being implemented; these intrinsics would be in the `core::asm::$ARCH` module and they could either be implemented by lowering to a LLVM intrinsics or using inline assembly. For example: ``` rust pub mod asm { @@ -113,150 +168,47 @@ pub mod asm { } ``` -These would be stable APIs with an unstable implementation. If LLVM assembler syntax the -implementations of these functions would have to be updated. +These would be stable APIs with an unstable implementation. If LLVM assembler syntax the implementations of these functions would have to be updated. -The embedded WG will submit an RFC proposing the `asm` module and that will include a list of -assembly operations that (a) are common and (b) need to be inlined for different architectures. +The embedded WG will submit an RFC proposing the `asm` module and that will include a list of assembly operations that (a) are common and (b) need to be inlined for different architectures. -- `#[used]` +### Unstable Feature #6: `#[used]` -This experimental feature has been in the compiler for a while and it's required in some scenarios -when using LTO to prevent the compiler some function / `static` that needs to be in the final -binary. +This experimental feature has been in the compiler for a while and it's required in some scenarios when using LTO to prevent the compiler some function / `static` that needs to be in the final binary. We'll try to get it stabilized by the edition release but it's not a high priority feature. -### Stability of the embedded targets +## Stability of the Embedded Targets -We don't only want to make embedded Rust possible on stable; we also want to make sure the embedded -targets don't regress. So we are going to add tests to rust-lang/rust CI to make sure regression -block PRs from landing. +We don't only want to make embedded Rust possible on stable; we also want to make sure the embedded targets don't regress. So we are going to add tests to rust-lang/rust CI to make sure regression block PRs from landing. -That effectively will make some of the embedded targets into the tier 1 platform. The core team is -fine with adding the thumb* targets (ARM Cortex-M) to tier 1; less maintained, still in -development and not fully mature targets like AVR, MSP430 and RISCV will become tier 3 -- they'll be -tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will -be binaries available for all nightly / beta / stable releases. +That effectively will make some of the embedded targets into the tier 1 platform. The core team is fine with adding the `thumb*` targets (ARM Cortex-M) to tier 1. Less maintained, still in development and not fully mature targets like AVR, MSP430 and RISCV will become tier 3 -- they'll be tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will be binaries available for all nightly / beta / stable releases. -We'll open an issue to discuss with the infra team the exact tests we want to add and track progress -on that, but have already told them about the kind of tests we want to add and they thought those -kind of tests are possible to implement. The kind of tests we discussed were: +We'll open an issue to discuss with the infra team the exact tests we want to add and track progress on that, but have already told them about the kind of tests we want to add and they thought those kind of tests are possible to implement. The kind of tests we discussed were: - It compiles and links - Runs the cross compiled binary in QEMU doesn't crash and exits with exit code 0. -- Tracking the binary size of a program compiled with `-Os` / `-Oz` and notify someone or fail the - build if the size regresses by 5% / 10% or something. - -### LLVM backends that are not yet in rustc - -There are two embedded LLVM backends that have not yet been enabled in rustc for different reasons: -AVR and RISCV. - -In the case of AVR the main reason is that some LLVM codegen bugs prevent you from building core for -AVR. These bugs are related to 128-bit integers and formatting floats. The libs team discussed this -some time ago and they decided they are fine with landing arch specific `#[cfg]` attributes to -remove 128-bit integers and other things like float APIs. - -In the case of RISCV the LLVM backend is currently under active development and our current version -of LLVM doesn't fully support RISCV. We would have to backport several patches to make RISCV work on -our LLVM version. The core team feels OK with backporting those patches as long as they have already -landed in upstream LLVM, and are not still under review. - -### Tooling - -Getting tooling for e.g. binary inspection (e.g. `objdump`) can be hard on some platforms (e.g. -Windows) specially for architecture which currently are not too widely used (e.g. RISCV). We can -improve the situation here by shipping llvm tools with the Rust toolchain -- with one set of those -tools you can inspect all the architectures that Rust supports. These are the thoughts of the core / -infra team regarding this: - -- We put these tools in the sysroot and have them always shipped with the Rust toolchain so no - `rustup component add` required -- this is already the case with `lld`. It might not be possible - to provide these tools on all platforms but it's very likely they'll be available on tier 1 - platforms. - -- We do *not* add these tools to the user `$PATH`. Instead some Cargo subcommand will be created by - the embedded WG (e.g. `cargo objdump`) and that subcommand will look for `llvm-objdump` in the - sysroot and do the right thing. +- Tracking the binary size of a program compiled with `-Os` / `-Oz` and notify someone or fail the build if the size changes by +/- 5-10% or something. -- We make no guarantees about the semantics and interface of these tools being preserved over time - (e.g. CLI changes, user facing output format changes, etc.). +## LLVM backends that are not yet in rustc -### The embedded Rust book +There are two embedded LLVM backends that have not yet been enabled in rustc for different reasons: AVR and RISCV. -We decided on an initial audience for the embedded book; we will be targeting people that know some -embedded stuff *and* some Rust. The main reason for this is that if someone knows one and not the -other then they can go and read existing Rust documentation or the Discovery book and then read the -embedded book. For more details check [rust-lang-nursery/embedded-wg#56]. +In the case of AVR the main reason is that some LLVM codegen bugs prevent you from building core for AVR. These bugs are related to 128-bit integers and formatting floats. The libs team discussed this some time ago and they decided they are fine with landing arch specific `#[cfg]` attributes to remove 128-bit integers and other things like float APIs. -[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56 - - -* [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018! -* [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier -* [emilgardis] and [ryankurte] are busy [refactoring] the [svd-parser] crate - -[japaric]: https://github.com/japaric -[hannobraun]: https://github.com/hannobraun -[jamesmunns]: https://github.com/jamesmunns -[mock embedded-hal]: https://github.com/rust-lang-nursery/embedded-wg/issues/70 -[stable embedded rust development]: https://github.com/rust-lang-nursery/embedded-wg/issues/42 -[refactoring]: https://github.com/japaric/svd/issues/46 -[svd-parser]: https://github.com/japaric/svd -[ryankurte]: https://github.com/ryankurte -[emilgardis]: https://github.com/Emilgardis +In the case of RISCV the LLVM backend is currently under active development and our current version of LLVM doesn't fully support RISCV. We would have to backport several patches to make RISCV work on our LLVM version. The core team feels OK with backporting those patches as long as they have already landed in upstream LLVM, and are not still under review. -## Embedded Projects +## Tooling -If you have an embedded project or blog post you would like to have featured in the Embedded WG Newsletter, make sure to mention it on the tracking issue for [the next newsletter], we would love to show it off! +Getting tooling for e.g. binary inspection (e.g. `objdump`) can be hard on some platforms (e.g. Windows) specially for architecture which currently are not too widely used (e.g. RISCV). We can improve the situation here by shipping llvm tools with the Rust toolchain -- with one set of those tools you can inspect all the architectures that Rust supports. These are the thoughts of the core / infra team regarding this: -### `embedded-hal` drivers +- We put these tools in the sysroot and have them always shipped with the Rust toolchain so no `rustup component add` required -- this is already the case with `lld`. It might not be possible to provide these tools on all platforms but it's very likely they'll be available on tier 1 platforms. +- We do *not* add these tools to the user `$PATH`. Instead some Cargo subcommand will be created by the embedded WG (e.g. `cargo objdump`) and that subcommand will look for `llvm-objdump` in the sysroot and do the right thing. +- We make no guarantees about the semantics and interface of these tools being preserved over time (e.g. CLI changes, user facing output format changes, etc.). -This is a list of recently released drivers that are part of the [Weekly Driver Initiative]. There are currently 5 Released Drivers, 14 WIP Drivers, and lots of TODOs! +### The Embedded Rust Book -* [danielgallagher0] has released their [hts221] humidity and temperature sensor driver -* [MrBuddyCasino] has released their I2C based [mcp9808] temperature sensor driver -* [Ilya Epifanov] has released their I2C based [si5351] CMOS clock generator driver, check out the [si5351 docs] for more info -* [Edwin Amsler] is working on their [axp209] PMIC driver -* [dbrgn] is working on their Sensirion [sgp30] low-power gas sensor driver -* [pcein] has started work on their [pcd8544] for SPI based LCD controllers used in displays like the Nokia 5110 -* [nordmoen] is working on their driver for the [hc-sr04] ultrasonic distance sensor +We decided on an initial audience for the embedded book; we will be targeting people that know some embedded stuff *and* some Rust. The main reason for this is that if someone knows one and not the +other then they can go and read existing Rust documentation or the Discovery book and then read the embedded book. For more details check [rust-lang-nursery/embedded-wg#56]. -[Weekly Driver Initiative]: https://github.com/rust-lang-nursery/embedded-wg/issues/39 -[danielgallagher0]: https://github.com/danielgallagher0 -[hts221]: https://medium.com/@pdanielgallagher/hts221-humidity-and-temperature-sensor-88056ea9e5fa -[MrBuddyCasino]: https://github.com/MrBuddyCasino -[mcp9808]: https://crates.io/crates/mcp9808 -[Ilya Epifanov]: https://github.com/ilya-epifanov -[si5351]: https://github.com/ilya-epifanov/si5351 -[si5351 docs]: https://docs.rs/si5351/0.1.5/si5351/ -[Edwin Amsler]: https://github.com/RandomInsano -[axp209]: https://github.com/RandomInsano/axp209-rs -[pcein]: https://github.com/pcein -[pcd8544]: https://github.com/pcein/pcd8544 -[dbrgn]: https://github.com/dbrgn -[sgp30]: https://github.com/dbrgn/sgp30-rs -[nordmoen]: https://github.com/nordmoen -[hc-sr04]: https://github.com/nordmoen/hc-sr04 - -### `embedded-hal` Board/Chip Support Crates - -* [DoumanAsh] has started work on their [stm32l4x6-hal] chip support crate - -[DoumanAsh]: https://github.com/DoumanAsh -[stm32l4x6-hal]: https://github.com/DoumanAsh/stm32l4x6_hal - -## Thanks - -> TODO: Thank some people from the other rust teams, like @nagisa, -> @oli-obk, and ??? - -## Help Wanted - -* [Simon Sapin] posted some working code for the [DS3234] SPI RTC, and is looking for someone to turn it into a maintained crate! - -[Simon Sapin]: https://github.com/SimonSapin -[DS3234]: https://github.com/rust-lang-nursery/embedded-wg/issues/39#issuecomment-375262785 - -If you have an embedded project that could use contributors or maintainers, leave a comment for [the next newsletter]! +[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56 \ No newline at end of file From 97e4f2aaebbfedaefc58350c45d83d6474e59d78 Mon Sep 17 00:00:00 2001 From: James Munns Date: Thu, 29 Mar 2018 16:58:10 +0200 Subject: [PATCH 4/6] Fix Thanks, mention issue @japaric mentioned --- newsletters/2018-03-29.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md index 64c1327d..ca0e7232 100644 --- a/newsletters/2018-03-29.md +++ b/newsletters/2018-03-29.md @@ -67,8 +67,12 @@ This is a list of recently released drivers that are part of the [Weekly Driver ## Thanks -> TODO: Thank some people from the other rust teams, like @nagisa, -> @oli-obk, and ??? +* Thanks to all of the Rust Team and Working Group members who took time at the All Hands to tackle some important Embedded Issues +* Thanks to [Alex Chrichton] who pushed a fix to a [linker issue] mentioned in our [last newsletter] + +[Alex Chrichton]: https://github.com/alexcrichton +[linker issue]: https://github.com/rust-lang/rust/pull/49316 +[last newsletter]: https://github.com/rust-lang-nursery/embedded-wg/blob/master/newsletters/2018-03-15.md ## Help Wanted From d49e4ca6a6d4248ed6851459d69289b1402542e4 Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Thu, 29 Mar 2018 18:23:33 +0200 Subject: [PATCH 5/6] s/tier 3/tier 2/ --- newsletters/2018-03-29.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md index ca0e7232..97948b4d 100644 --- a/newsletters/2018-03-29.md +++ b/newsletters/2018-03-29.md @@ -186,7 +186,7 @@ We'll try to get it stabilized by the edition release but it's not a high priori We don't only want to make embedded Rust possible on stable; we also want to make sure the embedded targets don't regress. So we are going to add tests to rust-lang/rust CI to make sure regression block PRs from landing. -That effectively will make some of the embedded targets into the tier 1 platform. The core team is fine with adding the `thumb*` targets (ARM Cortex-M) to tier 1. Less maintained, still in development and not fully mature targets like AVR, MSP430 and RISCV will become tier 3 -- they'll be tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will be binaries available for all nightly / beta / stable releases. +That effectively will make some of the embedded targets into the tier 1 platform. The core team is fine with adding the `thumb*` targets (ARM Cortex-M) to tier 1. Less maintained, still in development and not fully mature targets like AVR, MSP430 and RISCV will become tier 2 -- they'll be tested but won't block PRs and rust-std binaries will be produced but it's not guaranteed there will be binaries available for all nightly / beta / stable releases. We'll open an issue to discuss with the infra team the exact tests we want to add and track progress on that, but have already told them about the kind of tests we want to add and they thought those kind of tests are possible to implement. The kind of tests we discussed were: @@ -215,4 +215,4 @@ Getting tooling for e.g. binary inspection (e.g. `objdump`) can be hard on some We decided on an initial audience for the embedded book; we will be targeting people that know some embedded stuff *and* some Rust. The main reason for this is that if someone knows one and not the other then they can go and read existing Rust documentation or the Discovery book and then read the embedded book. For more details check [rust-lang-nursery/embedded-wg#56]. -[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56 \ No newline at end of file +[rust-lang-nursery/embedded-wg#56]: https://github.com/rust-lang-nursery/embedded-wg/issues/56 From 68f1bd149dbc11785a1d441970f8d283742a4308 Mon Sep 17 00:00:00 2001 From: Jorge Aparicio Date: Thu, 29 Mar 2018 18:23:56 +0200 Subject: [PATCH 6/6] fix typo in GH username --- newsletters/2018-03-29.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/newsletters/2018-03-29.md b/newsletters/2018-03-29.md index 97948b4d..8efc6b8e 100644 --- a/newsletters/2018-03-29.md +++ b/newsletters/2018-03-29.md @@ -11,7 +11,7 @@ If you want to mention something in [the next newsletter], make sure to leave a ## Highlights -* [drbgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier +* [dbrgn] has kicked off an investigation on how to [mock embedded-hal] to make testing sensors easier * [emilgardis] and [ryankurte] are busy [refactoring] the [svd-parser] crate * [japaric], [hannobraun], and [jamesmunns] from the [Embedded WG] attended the 2018 Rust All Hands in Berlin, working on our goal to make [stable embedded rust development] possible in 2018. See the bottom of this post for more details!