Push foundational crates to 1.0

[jamesmunns]

We would like to push embedded crates owned by the working group to a stable 1.0 state, when reasonably possible.

Possible crates to evaluate include:

• cortex-m
• cortex-m-rt
• embedded-hal

For each crate, we should come up with our process of deciding whether these crates are ready. This could include evaluation, a call for feedback, or could require identification of tasks required before ready for stabilization. This may spawn one or more focus projects.

For now, we need to do the following:

• Enumerate crates that can be included in the 1.0 push
• Come up with a process or evaluation criteria before marking them 1.0

In the 2020-01-07 meeting we agreed to try and push a crate out on a six week cycle (although not aligned with the Rust release process - just inspired by it).

First Wave - ships Tuesday, 2020-02-18

• r0 - Ship a 1.0 release r0#9

Second Wave

(Need to select from some of the following)

• cortex-m-rt - Ship a 1.0 release cortex-m#405
• bare-metal - Ship a 1.0 release bare-metal#22
• nb - Ship a 1.0 release nb#20 (note, this is a @japaric crate)
• Anything else r0 unblocks

Future Waves

• cortex-m - Ship a 1.0 release cortex-m#183
• embedded-hal - Ship a 1.0 release embedded-hal#177
• svd2rust - Ship a 1.0 release svd2rust#426
• cortex-m-semihosting - cortex-m-semihosting: Ship a 1.0 release cortex-m#290

[IGBC]

SVD2Rust?

[thejpster]

SVD2Rust?

Done

[jonas-schievink]

• cortex-m-semihosting (like it or not)
• nb (since it's a public dependency of embedded-hal)

Also, before releasing any crate as 1.0, the crate should've gone through an exhaustive review of the API Guidelines (any deviations from the guidelines should be made consciously).

[thejpster]

* `cortex-m-semihosting` (like it or not)
* `nb` (since it's a public dependency of `embedded-hal`)

Tickety tick.

Also, before releasing any crate as 1.0, the crate should've gone through an exhaustive review of the API Guidelines (any deviations from the guidelines should be made consciously).

Agreed.

[jonas-schievink]

As part of this effort, would it make sense to push embedded targets (at least ARMv7-M / thumbv7*) towards tier-1 support in Rust? Personally I'd love to see that happen, and making that a part of the 1.0 push makes sense from a marketing perspective to me.

There's also some non-crate-specific things that might need some discussion from the entire WG before going 1.0 with some crates: #418

[arrowcircle]

Just a little not, all of these repos, except cortex-m-rt, does not have at least one test.
It looks like a good hygienic thing to have at least minimal set of unit tests.
Any ideas on that?

[jonas-schievink]

r0 has tests, nb has tests, embedded-hal has tests, bare-metal has a compile-fail test and otherwise no API that really needs testing. cortex-m should indeed have more tests, possibly running in Qemu, same for semihosting but we might deprecate that crate instead.

[adamgreig]

Just to add some more very commonly used embedded crates: the panic handlers (panic-halt, panic-abort, panic-semihosting, etc) would be nice to get to 1.0 as well.

[arrowcircle]

@jonas-schievink
r0 have 2 tests inside src folder (thought it should go to tests).
nb (japaric/nb) does not have any tests.
embedded-hal does not have any tests.
Maybe we talking about different things?