cortex-m
cortex-m copied to clipboard
rust-embedded
Add new cortex-m-interrupt-number crate
Since #241 we've had an InterruptNumber trait in cortex-m, which is intended to be used by PACs to mark their enum of interrupts in a way that cortex-m's NVIC driver can use. We moved this out of the bare-metal crate because the implementation is architecture-dependent (u16 for cortex-m, but u8 or u32 for various other platforms).
However, in doing so we end up with all PACs having a direct dependency on cortex-m only for this trait. This makes it harder to release a new major version of cortex-m, because it's only allowed to have one cortex-m version in a project and most projects will use a PAC that depends on an older version, possibly indirectly via a HAL. Users are then stuck until their PAC (and probably HAL) update. In the past we've used semver hacks to make it possible to run different cortex-m versions alongside each other, but it's a lot of bug-prone work to make each release that way.
Instead, this PR moves InterruptNumber into its own crate, so PACs can depend on that instead of cortex-m, allowing us to more easily make breaking cortex-m changes in the future. We can make a backported cortex-m 0.7 release that depends on the new crate and publically re-exports it, and in upcoming cortex-m 0.8 we use it without re-exporting it to ensure the new crate is depended upon directly.
Builds on #487 which should be merged first. Incidentally CI fails because it can't check cortex-m because of the new dependency until it's been released.
If you @ me when the prior pr is in I can take a look
Thanks @thejpster, previous PR now merged so this one can be reviewed in isolation.
For the riscv environment, would it make sense to move the Exception and Interrupt enums to this crate? Or do you think it is better to have them duplicate in riscv and riscv-rt?
I think it makes sense for the RISC-V embedded rust world to have their own crate with their own trait for Interrupt numbering. There doesn't seem to be a good reason for someone to be able to plug a Cortex-M PAC that implements the trait into the RISC-V runtime which is looking for a trait implementation.
Yep, my plan is to create a new riscv-interrupt-number crate (or perhaps a more generic name, as I also plan to move priority numbers or HART ID numbers) that follows this fashion. But I wonder if I could also move the enums to this new crate, not only the traits
The number of interrupts varies depending on which Cortex-M based SoC you have, so it has to be defined in the PAC (or similar). But the runtime can't depend upon the PAC, and we don't want the PAC to depend upon the runtime, so now both depend on this shared trait. The PAC can create an enum to define what Interrupts are available and the runtime can deal with any enum as long as it implements this trait (which simply lets it convert the enum into an integer that the NVIC understands).