Porcelain and Plumbing

See: https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain

Perhaps cortex-m and cortex-m-rt could be split into two pieces in a different way. We would have one crate which is the plumbing for Cortex-M - it would handle the fundamentals of booting a Cortex-M core, interrupts, etc. Everyone, no matter what they were doing, would use this crate if they were on a Cortex-M. Then we have some porcelain, which is the nice user-facing bit. We might have several of those (for example, you could consider RTFM as some porcelain, or some RTOS). In a ideal world, the porcelain would fit with lots of different sorts of plumbing (risc-v-rt, msp430-rtc, etc), but sometimes a platform is just too weird for that to work.

We would perhaps need some traits (or some other API) to allow porcelain to access the plumbing, but it can be gritty and internal as users won't normally be exposed to it - they get exposed to the nice wipe-clean porcelain.

Example crates (some are fictional, for now)

Plumbing:

• cortex-m-plumbing
• risc-v-plumbing
• msp430-plumbing
• nrf9160-pac

Porcelain

• arduino-loop (some new crate I just made up - imagine it does a basic setup()/loop() thing like Arduino)
• freertos-rs (although being a C based RTOS it will have its own internal mechanism for handling types of CPU, imagine this is a pure-Rust equivalent to FreeRTOS)
• rtfm
• nrf52-hal

Start by reading the current cortex-m and cortex-m-rt crate boundaries and compare them with the plumbing and porcelain examples in the issue. Determine whether a stable API can separate Cortex-M boot and interrupt fundamentals from user-facing frameworks, then document the proposed crate responsibilities and compatibility implications.