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

FHSS timer: Use singleton pointer #9579

Merged
merged 1 commit into from
Feb 5, 2019

Conversation

JarkkoPaso
Copy link

Description

Use singleton pointer with FHSS timer.

Pull request type

[x] Fix
[ ] Refactor
[ ] Target update
[ ] Functionality change
[ ] Docs update
[ ] Test update
[ ] Breaking change

Reviewers

@JarkkoPaso
Copy link
Author

@kjbracey-arm Can I use singletonptr from array. Seems to work ok with array size of 2.

@kjbracey
Copy link
Contributor

kjbracey commented Feb 1, 2019

Yes, it's fine to enclose a SingletonPtr as a member of any other static object.

That would only be useful if that static object then becomes a simple object - ie it has no explicit constructor, and its default constructor now has nothing to do because none of its members have explicit constructors - all its complex C++ members are SingletonPtr-wrapped.

@cmonr
Copy link
Contributor

cmonr commented Feb 1, 2019

I'm curious. Why was this change needed? All I'm able to find is that a change was made, not why.

@cmonr
Copy link
Contributor

cmonr commented Feb 2, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Feb 2, 2019

Test run: SUCCESS

Summary: 12 of 12 test jobs passed
Build number : 1
Build artifacts

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 4, 2019

I'm curious. Why was this change needed? All I'm able to find is that a change was made, not why.

can you add this to the commit msg ? what is this addressing.

@JarkkoPaso
Copy link
Author

@kjbracey-arm Can you educate us regarding singletonptr?

@kjbracey
Copy link
Contributor

kjbracey commented Feb 4, 2019

It prevents the static objects always being included in a build. Without the SingletonPtr, blinky would still put those Timer objects in the image to run their constructor, with increased RAM and ROM usage.

If you have any top-level static C++ objects with constructors, wrapping them in SingletonPtr ensures that they are only included in the build if actually used - the constructor is run on first reference, not before main. And if never referenced, it's never constructed, and excluded by the linker altogether.

Tests should have flagged a blinky size increase when those objects were first added.

This is to save statically allocated memory. Without SingletonPtr the timer objects would always be included in build.
@JarkkoPaso
Copy link
Author

Thanks Kevin! I updated the commit message.

@0xc0170
Copy link
Contributor

0xc0170 commented Feb 4, 2019

CI started

@mbed-ci
Copy link

mbed-ci commented Feb 4, 2019

Test run: FAILED

Summary: 1 of 12 test jobs failed
Build number : 3
Build artifacts

Failed test jobs:

  • jenkins-ci/mbed-os-ci_greentea-test

@alekla01
Copy link
Contributor

alekla01 commented Feb 4, 2019

restarted jenkins-ci/greentea-test

@0xc0170 0xc0170 merged commit 95906f1 into ARMmbed:master Feb 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants