WIP: Split nb and can traits to separate crates.

[Dirbaio]

Following up from https://github.com/rust-embedded/embedded-hal/issues/177#issuecomment-1162212193, this PR splits nb and can traits to separate crates.

I propose keeping these crates (and embedded-hal-async) separate forever. (instead of merging EHA into EH when stable as we originally planned when we created EHA).

Reasons for splitting nb:

• its future is unclear. Some people who would like to see nb deprecated. By splitting, if we do deprecate it, we won't get stuck with it in the main embedded-hal crate forever.
• It makes the module paths in the main crate cleaner.
• Traits tied to a particular "execution model" in their own crates, which make the overall structure easier to understand IMO.

Reasons for splitting can:

• It has some open concerns: #381 #387
• Even if we do solve these, it's nice to have separate crates for the "more specialized" traits so that they can be major-bumped in the future if more concerns arise, without having to major-bump the main embedded-hal crate.

TODO:

• [ ] Move/remove docs/examples from the main crate that mention nb.
• [ ] Mention the subcrates from the main crate's docs.
• [ ] Add CI
• [ ] What should the nb, can crate versions be? 1.0? (no opinion on this from me).

[rust-highfive]

r? @ryankurte

(rust-highfive has picked a reviewer for you, use r? to override)

[burrbull]

Could you add links to -async and -nb crates in embedded-hal README.md ?

[adamgreig]

We discussed this a bunch at today's meeting (logs starting here), a few key points:

• Lots of support for splitting nb traits into embedded-hal-nb (and therefore keeping embedded-hal-async separate for good)
• For CAN, it seems like it might make most sense to use a new repository and publish to the old embedded-can crate rather than an embedded-hal-can; in general this approach seems favourable for more complicated protocols/peripherals/concepts like CAN, USB, DMA, etc (see also embedded-dma, embedded-i2s, etc). This way the CAN traits can change/have breaking releases/develop without impacting the embedded-hal crate versioning, without being much more work for HAL/driver/end users to actually use.

[ryankurte]

outcomes from https://github.com/rust-embedded/embedded-hal/pull/394#issuecomment-1195879618 sound good to me!

(looking forward to daylight savings here in a couple of months so the meetings are a paletable 08:00 instead of 06:00 here 🤣)

[adamgreig]

Discussed in today's meeting: Let's go with putting the CAN traits into an embedded-can folder in this repository, and then we can publish a new version of embedded-can with the latest traits from embedded-hal 0.2.

[Dirbaio]

bors try

[bors[bot]]

try

Build succeeded:

• test (1.54.0, x86_64-unknown-linux-gnu)
• test (nightly, thumbv6m-none-eabi)
• clippy
• test (1.54.0, thumbv7m-none-eabi)
• test (stable, x86_64-unknown-linux-gnu)
• test (stable, thumbv6m-none-eabi)
• test (stable, thumbv7m-none-eabi)
• test (1.54.0, thumbv6m-none-eabi)
• test (nightly, x86_64-unknown-linux-gnu)
• test (nightly, thumbv7m-none-eabi)
• fmt

[Dirbaio]

This should be now ready to go :) ping @rust-embedded/hal

The changelog checker is angry because I moved CHANGELOG.md to the subdir. How do we do this? Ideally the checker would require updating changelog for crate X only if you've touched files from subdir X, but it doesn't seem that's supported...

[Dirbaio]

Rebased, and split off the clippy stuff to a separate PR (#406)

[bors[bot]]

Build failed:

• clippy

[eldruin]

bors retry

[bors[bot]]

:-1: Rejected by too few approved reviews

[bors[bot]]

Build succeeded:

• fmt
• test (1.54.0, thumbv6m-none-eabi)
• test (1.54.0, thumbv7m-none-eabi)
• test (1.54.0, x86_64-unknown-linux-gnu)
• test (nightly, thumbv6m-none-eabi)
• test (nightly, thumbv7m-none-eabi)
• test (nightly, x86_64-unknown-linux-gnu)
• test (stable, thumbv6m-none-eabi)
• test (stable, thumbv7m-none-eabi)
• test (stable, x86_64-unknown-linux-gnu)