Cortex-M Team: Decide on 2019 objectives

[adamgreig]

As part of our 2019 planning, we want to figure out what each team wants to work on this year, including new ideas, items from the 2019 wishlist (#256), and any leftover items from this year.

Let's use this issue to come up with a list of possible items and then prioritise them.

[adamgreig]

I had a few thoughts...

• Remove the prebuilt objects from cortex-m and cortex-m-rt in favour of intrinsics or other native Rust code
• Unify the cortex-m and svd2rust peripheral APIs
• Support multiple bss/data sections in cortex-m-rt
• Figure out outstanding cortex-m-rt RFCs (uninit, late, ramfunc)

[thejpster]

I'd like us to start bring thumbv8m.{base,main} to up the same level as thumbv7{e,}m and thumbv6m, ready for all the new Cortex-M23 and Cortex-M33 parts coming on to the market.

[hug-dev]

I'd like us to start bring thumbv8m.{base,main} to up the same level as thumbv7{e,}m and thumbv6m, ready for all the new Cortex-M23 and Cortex-M33 parts coming on to the market.

@thejpster Very good point! I have already started working on that and I will be happy to participate in that goal, alongside maybe some other people from Arm

[japaric]

We discussed in yesterday's meeting (#290) that teams should start deciding on
how to prioritize their work items for this year. We'll let each team decide how
to do the item prioritization but we recommend having a real-time / synchronous
meeting (IRC or video meeting) to discuss all the potential goals.

If appropriate, you can reserve a time slot during the weekly meetings to have
this synchronous discussion. Just let us know in advance in one of the meeting
issues (e.g. #291).

Finally, if any of your goals for this year requires changes in any of the
rust-lang/* repositories and you haven't mentioned them in #256 or #269 then
please report them in #269 ASAP. We'll discuss prioritization of rust-lang
request during the next meeting (2019-01-15).

cc @rust-embedded/cortex-m

[korken89]

We are really good when it comes to usability and ease of use PoV already, but I'd like to have debugging be just as easy. We are already discussing debugging issues, but I'd like to hear if others have pain-points within the debugging workflow that they'd like to lift forward.

[adamgreig]

Summary from WG meeting at Oxidize:

• We'd like to release cortex-m 1.0 and cortex-m-rt 1.0 this year
• We'd need to resolve:
  • Using svd2rust API in cortex_m::peripheral
  • Better inline ASM, via intrinsics or otherwise
  • Better interrupt handling. Closures? NVIC splitting?
  • Improve Mutex (especially making it sound for multi-core systems)
  • Support multiple memory regions
  • Close up c-m-rt PRs (ramfunc, uninit, etc)
  • Maybe split cortex-m into a cortex-m-pac too
• Write a release checklist for ecosystem crates, to include testing with a clean checkout

[adamgreig]

I'd like to revitalise this a little and see if we can set some targets for cortex-m.

I think it would be good to focus on:

• Getting intrinsics into core
• Improve cortex_m's peripheral access:
  • Maybe use svd2rust
  • Maybe split it into a separate crate we re-export
  • Go through the documentation carefully to check we match exactly
• The cortex-m-rt RFCs around ramfunc, uninits, and others

I've already started an SVD describing the core peripherals (though confusingly many vendor SVDs partially describe them too), so that might be a starting point for the second item. I think polishing those SVDs, then making a new repository (cortex-m-pac perhaps) with the final SVDs and generated code, would be an attainable and productive goal.

I'm less sure what we'd have to do for the intrinsics; we've tried this before and it sort of petered out. Maybe we could get someone from the relevant Rust team to help mentor the effort.

The c-m-rt RFCs are the most open-ended and probably need some creativity and ingenuity, so would be a great candidate for someone to make a proof of concept of and see where we get to.

What do cortex-m members think? Anything anyone would like to take on or work together on? Any missing goals? @korken89 @thejpster @therealprof @ithinuel

[hannobraun]

@adamgreig

I've already started an SVD describing the core peripherals

You might already be aware of this, but I figured it won't hurt to link it: #100 (comment)

[eldruin]

2019 finished. Maybe we can create a follow up issue for 2020. Nominating for next week's meeting.

[adamgreig]

Closing as we're now well into 2020; if anything outstanding from this list is still relevant please add it to the not-yet-awesome embedded rust list, or create a new issue to track it.