Differentiate comparator 0 as the only one capable of cycle compare

[TDHolmes]

Statically enforces that only comparator 0 on armv7m can be configured for cycle comparison by introducing a marker trait differentiating comparator 0 and the rest of them, and only implementing the ability for this configuration on comparator 0.

Closes #376

[rust-highfive]

r? @adamgreig

(rust-highfive has picked a reviewer for you, use r? to override)

[TDHolmes]

🏷️ @tmplt

[TDHolmes]

I tested the cycle count comparison functionality on HW to make sure this all worked as expected. I'm not sure how to test the address compare functionality on HW so didn't check that.

[tmplt]

I don't see any outstanding issues reviewing from a phone at the moment. I'll go over it in detail when I'm back in my office next week.

[TDHolmes]

Thoughts @tmplt ?

[tmplt]

I'll go over it tomorrow.

[TDHolmes]

I made all of the DWT::has_* implementation feature checks associated functions instead of methods (they no longer take &self) per this comment as it allows me to check has_cycle_counter in configure.

edit: Looks like this was originally how it was implemented, but then you changed it in #342. Let me know if there was a good reason, but I think it makes sense to go back to associated functions.

[TDHolmes]

I also tried to be fancy by wrapping these two slightly different comparators in a unified struct which then vended the right one by implementing the Index trait, however it requires GATs to work :( it would've been cool because then we could've also checked DWT::num_comp to see if the comparator you're trying to access is even implemented. Oh well...

[TDHolmes]

Actually.. I suppose I could still implement Index where I return the type Result<ComparatorTypes, DwtError> where ComparatorTypes is an enum:

enum ComparatorTypes {
    NoCycleCount(Comparator<NoCycleCompare>),
    WithCycleCount(Comparator<HasCycleCompare>),

thoughts?

[tmplt]

Let me know if there was a good reason

At the time I thought it was relics from an older implementation which I refactored just to remove the unsafe usage.

As for Index I suggest limiting this PR to its namesake and create another one for the comparator implementation check.

[TDHolmes]

In that case this should be ready to review and merge

[tmplt]

I want to try this out on hardware before I sign off on it. Hopefully I'll have it done by next week.

[TDHolmes]

Sounds good, thanks!

[tmplt]

I've been testing this PR with a in cortex-m-rtic-trace branch, based on an rtic-scope-dw0 branch of cortex-m that contains this PR, for use with cargo-rtic-scope. Without the patch I see

hardware task - enter
software task - enter
software task - exit
hardware task - exit / overflow

With the patch I get a very confusing trace. I doubt this PR is at fault, but to make sure I need to handle #392 and #383 first.

[TDHolmes]

rebased onto latest master