Ship a 1.0 release

[thejpster]

Part of rust-embedded/wg#383

Might also involve rust-lang/rust#27731 so we can get rid of (some) of the inline asm / pre-compiled objects.

• Consider getting rid of aligned dependency subtree (Consider getting rid of aligned dependency subtree #184)
• Remove the const-fn feature
• Remove all currently #[deprecated] APIs
• Land Add cfg to Peripheral fields #181
  • Audit the crate for other things that should be #[cfg]d out depending on the target
• Make all types #[non_exhaustive] where it makes sense
• Use an svd2rust PAC instead of doing register access by hand
• Improve documentation of the Peripherals::steal() API, or redesign that API (Clarify / Document / Redesign the Peripherals::{take, steal} API #186)
• Make usage from multi-core chips sound
• Document that the inline-asm feature is completely unstable and semver-exempt
• Document availability of target-specific APIs (using #[doc(cfg(X))] where possible)
• Fix soundness bug in cache maintenance API "Invalidate Cache" operation is unsafe #188
• Fix soundness bugs around MMIO in general (deal with rustc/LLVM bug around LLVM's dereferenceable and volatile ops wg#387)
• Review against API guidelines
• Update to bare-metal 1.0 (one released)
• ...

[jonas-schievink]

Might also involve rust-lang/rust#27731 so we can get rid of (some) of the inline asm / pre-compiled objects.

This is not needed for 1.0 since it doesn't change the public API

[jonas-schievink]

Easy (breaking) improvements to do before 1.0:

• Remove the const-fn feature
• Get Add cfg to Peripheral fields #181 landed and audit the crate for other things that should be #[cfg]d out depending on the target

Other 1.0-quality things that I'd like to see:

• Improve overall documentation, especially around the take/steal API (and maybe improve that API)
• Document that the inline-asm feature is unstable (semver-exempt) and nightly-only

This is also blocked on sound MMIO. Currently we use volatile-register here. As #184 mentions, there's also a public dependency on aligned that we should get rid of (or also bring to 1.0).

[adamgreig]

I'd really want to see cortex-m move to using svd2rust-generated API for accessing the Cortex-M peripherals, i.e. a cortex-m-pac crate that cortex-m depends on and adds the HAL API. I've made some progress towards generating a suitable set of SVD files already and plan to finish it fairly soon.

[thejpster]

I'd really want to see cortex-m move to using svd2rust-generated API for accessing the Cortex-M peripherals, i.e. a cortex-m-pac crate that cortex-m depends on and adds the HAL API. I've made some progress towards generating a suitable set of SVD files already and plan to finish it fairly soon.

Yeah, this would likely fundamentally change our public API so if we are ever going to do it, pre 1.0 is best.

[jonas-schievink]

Also:

• Remove currently #[deprecated] unsound APIs (I expect we'll publish 0.7 before 1.0, so it would be good to do all breaking changes there)

[adamgreig]

I'd add:

• Check all peripheral methods that could be static are, i.e. don't unnecessarily require a reference to the peripheral for safe/atomic operations. We've had a number of breaking changes moving things from methods to associated functions and the latter are easier to use, so we should proactively see if we can do any more.

[Disasm]

With the new CriticalSection type interrupt::free() should pass CriticalSection by value instead of by reference.

[tmplt]

@adamgreig any updates on the svd2rust generation? Is there a tracking issue for it?

[Gryhyphen]

So this is embeded-hal 1.0 incompatibility? Was working on updating my dependencies and found that cortext-m was relying on embedded-hal v0.2.7, so having embdedded-hal v1.0.0 is not possible if we want to use cortext-m atm? If I'm understanding correctly?

[adamgreig]

cortex-m currently uses embedded-hal 0.2, but it's not a problem to have both embedded-hal 0.2 and 1.0 in a project at the same time. That way you can use embedded-hal 1.0 and all the drivers and HALs that use it at the same time as using cortex-m.