Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

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

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 ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
TDHolmes wants to merge10 commits intorust-embedded:master
base:master
Choose a base branch
Loading
fromTDHolmes:differentiate-comparator-0

Conversation

TDHolmes
Copy link
Contributor

Statically enforces that only comparator 0 onarmv7m 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
Copy link

r?@adamgreig

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

@rust-highfiverust-highfive added S-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties. T-cortex-m labelsJan 2, 2022
@TDHolmes
Copy link
ContributorAuthor

🏷️@tmplt

@TDHolmes
Copy link
ContributorAuthor

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

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 reacted with hooray emoji

@TDHolmes
Copy link
ContributorAuthor

Thoughts@tmplt ?

@tmplt
Copy link
Contributor

I'll go over it tomorrow.

TDHolmes reacted with thumbs up emoji

/// 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
ContributorAuthor

@TDHolmesTDHolmesJan 6, 2022
edited
Loading

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 argumentSupportedFunctions, but it's zero sized so we usePhantomData. As the tests show, it does not increase the size of theRegisterBlock (addresses forcomp0 and more importantlycomp[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 testconfigure here?

Copy link
ContributorAuthor

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

@TDHolmesTDHolmesforce-pushed thedifferentiate-comparator-0 branch fromc8a4fdb to0dc7047CompareJanuary 6, 2022 21:57
@TDHolmes
Copy link
ContributorAuthor

TDHolmes commentedJan 6, 2022
edited
Loading

I made all of theDWT::has_* implementation feature checks associated functions instead of methods (they no longer take&self) perthis comment as it allows me to checkhas_cycle_counter inconfigure.

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
ContributorAuthor

TDHolmes commentedJan 6, 2022
edited
Loading

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 theIndex trait, however it requires GATs to work :( it would've been cool because then we could've also checkedDWT::num_comp to see if the comparator you're trying to access is even implemented. Oh well...

@TDHolmes
Copy link
ContributorAuthor

TDHolmes commentedJan 6, 2022
edited
Loading

Actually.. I suppose I could still implementIndex where I return the typeResult<ComparatorTypes, DwtError> whereComparatorTypes is an enum:

enumComparatorTypes{NoCycleCount(Comparator<NoCycleCompare>),WithCycleCount(Comparator<HasCycleCompare>),

thoughts?

@tmplt
Copy link
Contributor

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 theunsafe usage.

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

TDHolmes reacted with thumbs up emoji

@TDHolmes
Copy link
ContributorAuthor

In that case this should be ready to review and merge

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
ContributorAuthor

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

@tmplt
Copy link
Contributor

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
ContributorAuthor

Sounds good, thanks!

@tmplt
Copy link
Contributor

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

hardware task - entersoftware task - entersoftware task - exithardware 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 reacted with thumbs up emoji

Statically enforces that only comparator 0 on `armv7m` can be configuredfor cycle comparison by introducing a marker trait differentiatingcomparator 0 and the rest of them, and only implementing the ability forthis configuration on comparator 0.Closesrust-embedded#376
@TDHolmesTDHolmesforce-pushed thedifferentiate-comparator-0 branch fromb666289 to457864dCompareOctober 8, 2022 18:58
@TDHolmes
Copy link
ContributorAuthor

rebased onto latest master

@TDHolmesTDHolmesforce-pushed thedifferentiate-comparator-0 branch froma41ceeb toef728e8CompareOctober 8, 2022 21:28
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Reviewers

@tmplttmplttmplt requested changes

At least 1 approving review is required to merge this pull request.

Assignees

@adamgreigadamgreig

Labels
S-waiting-on-reviewStatus: Awaiting review from the assignee but also interested parties.T-cortex-m
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

DWT: differentiate the first comparator
4 participants
@TDHolmes@rust-highfive@tmplt@adamgreig

[8]ページ先頭

©2009-2025 Movatter.jp