AOD fixup

[mark9064]

• Removed ROUNDED_DIV macro which doesn't make sense to rely on here (it's from the NRF SDK).
  • Would an namespace {} function be better than the inline one? Any ideas?
• Motion is now updated when in AOD (as watchfaces display steps and this should update if in AOD).
• Idle refresh rate increased from 2Hz to 8Hz. This reduces visible display strobing in AOD particularly on apps with a brighter background such as Twos

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)

[github-actions[bot]]

Build size and comparison to main:

Section	Size	Difference
text	374200B	-32B
data	948B	0B
bss	63480B	0B

[mark9064]

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

[mark9064]

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

[JF002]

I've just measured the power usage with BLE disabled :

• 1.14 for reference in sleep mode : 413µA
• main in sleep mode : 400µA
• main AOD : 3mA
• aod-fixup (this PR) in sleep mode : 400µA
• aod-fixup (this PR) in AOD mode : 3.2mA

So there's a slight increase in power usage with this PR (3.0 -> 3.2mA). I guess this increase comes from the 8Hz refresh rate. I'll let @mark9064 decide if this is a acceptable compromise :)

---

@JF002 you suggested a state diagram or similar in https://github.com/InfiniTimeOrg/InfiniTime/pull/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

Good question! I like PlantUML diagrams because they are "diagram as code" : easy to edit and easy to integrate in Git. But feel free to use/suggest any other diagram system ;-)

[mark9064]

Thanks for the power testing 😄

Yep that lines up well with my experience in terms of battery life, it's a minor hit but well worth it to avoid strobing IMO

I'm happy to do a PlantUML (I've used it before actually), I guess I'll queue up a new PR when that's done?

[JF002]

I'm happy to do a PlantUML (I've used it before actually), I guess I'll queue up a new PR when that's done?

Yeah sure, just open a new PR when it's ready ;)