-
Notifications
You must be signed in to change notification settings - Fork 2k
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
cpu/msp430: implement power management #20613
Merged
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
added
Platform: MSP
Platform: This PR/issue effects MSP-based platforms
Area: cpu
Area: CPU/MCU ports
labels
Apr 23, 2024
maribu
added
the
State: waiting for other PR
State: The PR requires another PR to be merged first
label
Apr 25, 2024
Now with low symbol rates working on the MSP430 F2xx, it turned out that the auxiliary clock will not be auto-acquired by the USCI. (The datasheet indeed does only claim that the SMCLK will be acquired as needed by the UART peripheral, so this does check out.) Anyway, fixed :) |
benpicco
added
CI: ready for build
If set, CI server will compile all applications for all available boards for the labeled PR
and removed
State: waiting for other PR
State: The PR requires another PR to be merged first
labels
Apr 26, 2024
The register r2 is the status register, which has the SR alias. Using SR is a lot more readable than r2.
This implements `pm_set_lowest()` for the MSP430. Unlike most other platforms, it intentionally does not use pm_layered. It is pretty similar to `pm_layered` in that is does use reference counters, but it uses them for two independent clock sources. The main difference is that the low frequency clock domain can be disabled even when the high frequency clock is still active. With the layers, disabling layer n-1 while layer n is still blocked would not work.
rebased on top of #20623 |
benpicco
approved these changes
May 6, 2024
github-merge-queue
bot
removed this pull request from the merge queue due to failed status checks
May 6, 2024
maribu
requested review from
miri64,
leandrolanzieri,
aabadie and
MichelRottleuthner
as code owners
May 7, 2024 05:58
github-actions
bot
added
Area: tests
Area: tests and testing framework
Area: examples
Area: Example Applications
labels
May 7, 2024
Thx a bunch :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Area: cpu
Area: CPU/MCU ports
Area: examples
Area: Example Applications
Area: tests
Area: tests and testing framework
CI: ready for build
If set, CI server will compile all applications for all available boards for the labeled PR
Platform: MSP
Platform: This PR/issue effects MSP-based platforms
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Contribution description
This implements power management for the MSP430.
Testing procedure
Flash this on any MSP430 board. No regressions should occur, but power consumption should drop. Your mileage may wary, though:
Benchmarks
I attached a power monitor in-between the USB connection to our Olimex MSP430Hxxx breakout board and monitored the power consumption in the following scenarios:
/dev/ttyUSB0
open). This is the baseline, as this power is used even without the MCU actually attachedexmaples/default
frommaster
flashed, and firsthelp
thenps
runexmaples/default
from this PR flashed, and firsthelp
thenps
runBenchmark on the
olimex-msp430h1611
Benchmark on the
olimex-msp430h2618
Conclusion
The power consumption goes down pretty much to the base line for each MCU family while the MCU is not in use, but spikes when there is activity. It looks pretty much like one would expect.
Issues/PRs references