-
-
Notifications
You must be signed in to change notification settings - Fork 930
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
AOD fixup #2106
base: main
Are you sure you want to change the base?
AOD fixup #2106
Conversation
Build size and comparison to main:
|
This PR now depends on #2109 Looking at AOD again, re-using Idle in DisplayApp and Sleeping in SystemTask wasn't a great idea as these states now have 2 different meanings depending on whether AOD is enabled. Also, if something changes the AOD enablement state while in AOD, all hell breaks loose (currently this isn't possible, but an auto wake/sleep pr like is currently proposed would cause problems here) and generally a brittle design like this is something to avoid. So this PR will also add a new AODSleeping state to SystemTask and an AOD state to DisplayApp. But adding those states depends on the state refactor, as the waking up state gets in the way among other things |
Code changes are now ready to review The power of 8Hz idle should still be checked. Based off how battery life is for me it is worse but not by much, and noticeable flickering is resolved @JF002 you suggested a state diagram or similar in #2109 which I didn't have a chance to finish before merging. This PR adds a few states anyway so perhaps that was for the best! Anyway, what format do you think would work best? ASCII diagram in the code somewhere (if so where)? SVG state diagram? I'm not really sure how to present it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't have a voltage meter. But the code changes are nice. More explicit AOD states is good in my opinion
ROUNDED_DIV
macro which doesn't make sense to rely on here (it's from the NRF SDK).Before merging this the power impact of the 8Hz idle commit needs to be tested; if it uses a lot more energy then it might not be worth the improved visuals. I don't have a power profiler so I'd really appreciate if someone could compare AOD power usage with that commit applied directly to main compared to current main (other commits in this branch like motion updates could affect results)