Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Differentiate comparator 0 as the only one capable of cycle compare #377

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

TDHolmes
Copy link
Contributor

@TDHolmes TDHolmes commented Jan 2, 2022

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

@TDHolmes TDHolmes requested a review from a team as a code owner January 2, 2022 00:27
@rust-highfive
Copy link

r? @adamgreig

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

@rust-highfive rust-highfive added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-cortex-m labels Jan 2, 2022
@TDHolmes
Copy link
Contributor Author

TDHolmes commented Jan 2, 2022

🏷️ @tmplt

@TDHolmes
Copy link
Contributor Author

TDHolmes commented Jan 2, 2022

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
Copy link
Contributor

tmplt commented Jan 2, 2022

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
Copy link
Contributor Author

TDHolmes commented Jan 5, 2022

Thoughts @tmplt ?

@tmplt
Copy link
Contributor

tmplt commented Jan 5, 2022

I'll go over it tomorrow.

CHANGELOG.md Outdated Show resolved Hide resolved
src/peripheral/dwt.rs Outdated Show resolved Hide resolved
/// Comparator
pub comp: RW<u32>,
/// Comparator Mask
pub mask: RW<u32>,
/// Comparator Function
pub function: RW<Function>,
reserved: u32,
_supported_functions: core::marker::PhantomData<SupportedFunctions>,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What effect does this have?

Copy link
Contributor Author

@TDHolmes TDHolmes Jan 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not 100% sure what you mean so I'll take a stab at what I think you're asking. We need to "cary" around the generic argument SupportedFunctions, but it's zero sized so we use PhantomData. As the tests show, it does not increase the size of the RegisterBlock (addresses for comp0 and more importantly comp[0] remained the same)

assert_eq!(address(&dwt.comp[0].comp), 0xE000_1020);
assert_eq!(address(&dwt.comp[0].mask), 0xE000_1024);
assert_eq!(address(&dwt.comp[0].function), 0xE000_1028);
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we test configure here?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think so unfortunately. These tests run on the native host so the best we can do is make sure these things are pointing to the right address. If we dereferenced them and tried to check behavior, we'd crash and burn

@TDHolmes
Copy link
Contributor Author

TDHolmes commented Jan 6, 2022

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
Copy link
Contributor Author

TDHolmes commented Jan 6, 2022

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
Copy link
Contributor Author

TDHolmes commented Jan 6, 2022

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
Copy link
Contributor

tmplt commented Jan 7, 2022

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
Copy link
Contributor Author

TDHolmes commented Jan 7, 2022

In that case this should be ready to review and merge

src/peripheral/dwt.rs Outdated Show resolved Hide resolved
CHANGELOG.md Outdated
@@ -20,6 +25,9 @@ and this project adheres to [Semantic Versioning](http://semver.org/).

### Fixed
- Fixed `singleton!()` statics sometimes ending up in `.data` instead of `.bss` (#364, #380).
- Corrected `SCB.ICSR.VECTACTIVE`/`SCB::vect_active()` to be 9 bits instead of 8.
Also fixes `VectActive::from` to take a `u16` and subtract `16` for
`VectActive::Interrupt`s to match `SBC::vect_active()` (#373).
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Transient changes from another PR?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I failed to update the changelog in my original PR so sneaking it in here

src/peripheral/dwt.rs Outdated Show resolved Hide resolved
@tmplt
Copy link
Contributor

tmplt commented Jan 8, 2022

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

@TDHolmes
Copy link
Contributor Author

TDHolmes commented Jan 8, 2022

Sounds good, thanks!

@tmplt
Copy link
Contributor

tmplt commented Jan 13, 2022

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.

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 rust-embedded#376
@TDHolmes
Copy link
Contributor Author

TDHolmes commented Oct 8, 2022

rebased onto latest master

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-cortex-m
Projects
None yet
Development

Successfully merging this pull request may close these issues.

DWT: differentiate the first comparator
4 participants