Skip to content

Initialize Blog using Gutenberg #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Aug 26, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
28 changes: 28 additions & 0 deletions config.toml
Original file line number Diff line number Diff line change
@@ -0,0 +1,28 @@
# The URL the site will be built for
base_url = "https://blog.rust-embedded.org"

title = "Rust Embedded Working Group"
description = """
Blog of the Embedded Rust Working Group
"""

# Whether to automatically compile all Sass files in the sass directory
compile_sass = true

# Whether to do syntax highlighting
# Theme can be customised by setting the `highlight_theme` variable to a theme supported by Gutenberg
highlight_code = true

# Whether to build a search index to be used later on by a JavaScript library
build_search_index = true

theme = "hyde"

generate_rss = true

[extra]
hyde_links = [
{url = "https://rust-lang.org", name = "The Rust Language"},
{url = "https://github.com/rust-embedded/wg", name = "Embedded WG"},
{url = "https://github.com/rust-embedded/blog", name = "The Blog on GitHub"},
]
89 changes: 89 additions & 0 deletions content/2018-03-15.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,89 @@
+++
title = "The Embedded Working Group Newsletter - 1"
date = 2018-03-15
draft = false
in_search_index = true
template = "page.html"
+++

This is the first newsletter of the [Embedded WG]! We will be releasing this newsletter on a bi-weekly basis, and we are looking to highlight new progress, celebrate cool projects, thank the community, and advertise projects that need help!

<!-- more -->

If you want to mention something in [the next newsletter], make sure to leave a comment on the issue!

## Highlights

* [Tock-OS] has released the [1.0 of their kernel], gotten the Rust Userspace library back in order, and are working on a [new register interface]
* [Emilgardis], [jamesmunns] and [ryankurte] have become collaborators of the [svd] and [svd2rust] projects.
* [hannobraun], [ilya-epifanov], [thejpster], [therealprof] have become collaborators of the [embedded-hal] project.
* [dvc94ch] has created the [riscv-rust] organization for all your embedded RISCV needs!
* [dylanmckay] has begun [rebasing][avr-rust-rebase] the avr-rust/rust fork onto a recent rust-lang/rust version, bringing in LLVM 6.0 support.

## 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!

* [pcein] has [released][pcein-blog] the third weekly driver for the [`adc-mcp3008`], an 8-channel 10-bit ADC.
* [japaric] has [released][enc-blog] the fourth weekly driver for the [`enc28j60`], an Ethernet controller with SPI interface.
* [dbrgn] has [released][mcp-blog] the fifth weekly driver for the [`mcp3425`], a 16-bit ADC with I2C interface.

## Thanks

* Thanks to everyone who has been commenting on the [Embedded WG Issues], especially for the [Embedded Rust Book] tracking issue!
* [varkor] has fixed a [long standing LLVM bug][gh41315], that artificially increased the binary size of Rust programs, and backported the patch to rustc.
* LLD is now being shipped with the Rust toolchain. [FenrirWolf] [patched Xargo][xargo-lld] so that Xargo users can make use of it too.

## Help Wanted

If you have an embedded project that could use contributors or maintainers, leave a comment for [the next newsletter]!

* We are [pretty close][cortex-m-rt-lld] to being able to use LLD to link Rust programs compiled for ARM Cortex-M but there are some [LLD bugs][lld-issues] that still need to be fixed. Help reporting these bugs upstream would be greatly appreciated!
* Incremental compilation is in the roadmap for this year but it doesn't work with `no_std` binaries due to an [old rustc bug][gh18807] related to linking. Help us fix it! There's a proposed solution [here].
* We want to explore stabilizing some assembly operations in core as an alternative to the unstable asm! macro. We would love some help identifying the assembly operations that need to be provided this way as some can be implemented in external assembly files without losing
semantics. Details in issue [#63].

[#63]: https://github.com/rust-lang-nursery/embedded-wg/issues/63
[1.0 of their kernel]: https://www.tockos.org/blog/2018/talking-tock-35/
[`adc-mcp3008`]: https://crates.io/crates/adc-mcp3008
[`enc28j60`]: https://crates.io/crates/enc28j60
[`mcp3425`]: https://crates.io/crates/mcp3425
[avr-rust-rebase]: https://github.com/avr-rust/rust/pull/91
[cortex-m-rt-lld]: https://github.com/japaric/cortex-m-rt/issues/53
[dbrgn]: https://github.com/dbrgn
[dvc94ch]: https://github.com/dvc94ch
[dylanmckay]: https://github.com/dylanmckay
[Embedded Rust Book]: https://github.com/rust-lang-nursery/embedded-wg/issues/56
[Embedded WG Issues]: https://github.com/rust-lang-nursery/embedded-wg/issues
[Embedded WG]: https://github.com/rust-lang-nursery/embedded-wg
[embedded-hal]: https://github.com/japaric/embedded-hal
[Emilgardis]: https://github.com/Emilgardis
[enc-blog]: http://blog.japaric.io/wd-4-enc28j60/
[FenrirWolf]: https://github.com/FenrirWolf
[gh18807]: https://github.com/rust-lang/rust/issues/18807
[gh41315]: https://github.com/rust-lang/rust/issues/41315
[hannobraun]: https://github.com/hannobraun
[here]: https://github.com/rust-lang/rust/issues/47074#issuecomment-354588718
[ilya-epifanov]: https://github.com/ilya-epifanov
[jamesmunns]: https://github.com/jamesmunns
[japaric]: https://github.com/japaric
[lld-issues]: https://github.com/japaric/cortex-m-rt/issues/53#issuecomment-371972935
[mcp-blog]: https://blog.dbrgn.ch/2018/3/13/rust-mcp3425-driver/
[new register interface]: https://www.tockos.org/blog/2018/talking-tock-36/
[pcein]: https://github.com/pcein
[pcein-blog]: http://pramode.in/2018/02/24/an-introduction-to-writing-embedded-hal-based-drivers-in-rust/
[riscv-rust]: https://github.com/riscv-rust
[ryankurte]: https://github.com/ryankurte
[svd2rust]: https://github.com/japaric/svd2rust
[svd]: https://github.com/japaric/svd
[the next newsletter]: https://github.com/rust-lang-nursery/embedded-wg/issues/65
[thejpster]: https://github.com/thejpster
[therealprof]: https://github.com/therealprof
[Tock-OS]: https://github.com/helena-project/tock
[varkor]: https://github.com/varkor
[Weekly Driver Initiative]: https://github.com/rust-lang-nursery/embedded-wg/issues/39
[xargo-lld]: https://github.com/japaric/xargo/pull/200
224 changes: 224 additions & 0 deletions content/2018-03-29.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,224 @@
+++
title = "The Embedded Working Group Newsletter - 2"
date = 2018-03-29
draft = false
in_search_index = true
template = "page.html"
+++

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!

<!-- more -->

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

* [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!

[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

* 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

* [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]!

# 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

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:

### Unstable Feature #1: `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 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

### 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]`.

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;

// 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.

**Tracking issue:** [rust-lang/rust#49380]

[rust-lang/rust#49380]: https://github.com/rust-lang/rust/issues/49380

### 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]).

[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.

[nagisa]: https://github.com/nagisa

## Non critical unstable features

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

### 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.

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 intrinsic 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 changes, 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.

### 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 from dead-stripping 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 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:

- 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 changes 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
Loading