[RFC] multiarch support for svd2rust

[japaric]

Background

@pftbest has been doing a great work at getting msp430 support at the
cortex-m-quickstart level by porting a bunch of cortex-m-* crates to msp430.
They also have a fork of svd2rust that can generate msp430 device crates from
msp430 SVD files.

In parallel @ahixon has been working with bare metal Cortex-A processors and
they also want to be able to use svd2rust to generate a device crate for their
Cortex-A processor.

This RFC / PR is about adding multiarch support to svd2rust to support these two
cases.

How

As @ahixon suggested this RFC proposes moving non Cortex-M bits from the
cortex-m crate into a common crate: the mcu crate. Both the cortex-m
crate and the msp430 crate, its MSP430 counterpart, will re-export the common
code from the mcu crate in their APIs. The shared API includes:

• the Nr trait
• the Peripheral struct
• the CriticalSection struct
• the Mutex struct

Additionally svd2rust will be tweaked to generate code that depends on the mcu
crate rather than on the cortex-m crate where possible.

Finally, a --target flag that accepts the values "cortex-m", "msp430" and
"none" will be added to the svd2rust tool. This flag tweaks code generation.
When "msp430" is selected the generated crate will depend on the msp430 crate
and optionally (#[cfg(feature = "rt")]) on the msp430-rt crate. The
"cortex-m" value has a similar effect. The "none" flag forces the generated
crate to not depend on any specific architecture crate.

Unresolved questions

• Is there a better name for the mcu crate?

• --target or --arch?

Implementation bits

• cortex-m
• svd2rust: this PR
• msp430
• msp430-rt
• msp430g2553
• msp430-quickstart, a demo

cc @awygle

[awygle]

I vote for --target. --arch would preclude us from having multiple targets which use the same MCU architecture, which I could see wanting in the future.

Without knowing a ton about the mcu crate, I wouldn't call a Cortex-A an MCU, so if you envision the A's using the crate I'd call it something else.

[pftbest]

Looks good! Agreed with @awygle on --target flag name.

Don't know a better name for mcu. Maybe I would have named it as mcu_common or mcu_support to denote that it's not very useful as standalone crate, but is just a part of a bigger ecosystem.

P.S.
Sorry, didn't notice the pull requests.

[brson]

Oh, man so much good stuff happening. Thanks @pftbest and @ahixon.

[japaric]

Alright let's go ahead with --target instead of --arch.

As for renaming mcu, how does embedded-common sound? I originally wanted to name that crate embedded but the name is already taken on crates.io.

@ahixon, I would love to hear if the changes in this PR are enough for your use case.

[ahixon]

Hah, good timing! I only just got back from a short holiday and am going through my Github notifications now.

Another +1 for --target.

Also agree with the mcu name not fully encompassing the crate's purpose. embedded-common sounds good, though!

Otherwise, yeah, this looks great! :)

[awygle]

embedded-common is definitely better, but it feels a little bit vague ("embedded" doesn't really mean anything - is a Cortex-A5 embedded? What about an A-53?). Again, stressing that I haven't really dug into what the proposed crate would include (I've been stupid-busy - thanks @pftbest for continuing great work!), maybe the names baremetal or baremetal-common are a better fit?

[japaric]

I have gone with bare-metal for the name. The crate is now on crates.io

Thanks everyone for the input. Let's land this.

@homunkulus r+

[homunkulus]

📌 Commit ffcc983 has been approved by japaric

[homunkulus]

⌛ Testing commit ffcc983 with merge ffcc983...

[japaric]

@homunkulus r+

[homunkulus]

📌 Commit c7aed0a has been approved by japaric

[homunkulus]

⌛ Testing commit c7aed0a with merge c7aed0a...

[homunkulus]

☀️ Test successful - status-appveyor, status-travis
Approved by: japaric
Pushing c7aed0a to master...