Skip to content
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

Ship a 1.0 release #183

Open
5 of 16 tasks
thejpster opened this issue Jan 7, 2020 · 8 comments
Open
5 of 16 tasks

Ship a 1.0 release #183

thejpster opened this issue Jan 7, 2020 · 8 comments
Milestone

Comments

@thejpster
Copy link
Contributor

thejpster commented Jan 7, 2020

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.

@jonas-schievink
Copy link
Contributor

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
Copy link
Contributor

jonas-schievink commented Jan 9, 2020

Easy (breaking) improvements to do before 1.0:

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
Copy link
Member

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
Copy link
Contributor Author

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 jonas-schievink added this to the 1.0.0 milestone Jan 9, 2020
@jonas-schievink
Copy link
Contributor

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
Copy link
Member

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
Copy link
Member

Disasm commented Feb 8, 2020

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

@tmplt
Copy link
Contributor

tmplt commented Jan 4, 2022

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

adamgreig added a commit that referenced this issue Jan 12, 2022
183: Update cortex-m version requirement to allow using 0.6.0 r=therealprof a=adamgreig

See also rust-embedded/cortex-m-semihosting#32

Co-authored-by: Adam Greig <adam@adamgreig.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants