Always on display

[KaffeinatedKat]

I have added an option in the "Display timeout" for an always on display. Not sure how useful this is, or how good the battery life is (will be testing this and will post a comment with how long the battery lasted).

Any suggestions on how I could possibly increase the battery with the display always on would be great.

[mark9064]

InfiniSim PRs now done, so should be good on that front

[mark9064]

I've removed the commits that have been split with the goal of making review simpler. This PR now soft-depends on #2041 #2043 #2042 #2046 (they are required for AOD to work but it compiles without them)

Edit: whitespace fixes, somehow ended up with bad formatting even with the pre-commit hook?

[FintasticMan]

The pre-commit hook doesn't affect commits during a rebase (unless you edit them).

[mark9064]

Ah makes sense, that's probably it

[mark9064]

Just locked down the last annoying issue with frame pacing. Apparently the LVGL task handler can return before it's finished all its work (but it at least tells you that this has happened!)

With that this PR has all outstanding (feature-wise) issues resolved :)

I'm still mulling over how to optimise the backlight power further, it's quite difficult to know how the hardware is going to behave power-wise without a profiler myself (documentation isn't great so I'm making 'educated' guesses here). Same goes for optimising LCD power.

I don't think I've got any more changes to make to AOD now, so this is definitely ready for review (as well as the PRs it depends on). This PR could be split further if review is difficult, but I won't spam the repo with any more AOD PRs for now :sweat_smile:

PS: I also ported #1870 locally and it's looking great!

[JF002]

Thanks for your extensive work on this feature and on both InfiniTime and InfiniSim @mark9064 ! I'll definitively have a look at those PR ASAP!

[mark9064]

Changelog:

• RTC based backlight rather than using the TIMER peripheral. Means that the high frequency clock doesn't need to be kept running the whole time. Should save some power
• Fixed displayapp spinning infinitely when LVGL is very busy (causes system lockups)

Notes:

• Once #2059 is reviewed/merged I'll update this PR based on that
• This PR can be tested on hardware now since #2042 and #2046 are merged

If someone could do a power comparison between https://github.com/InfiniTimeOrg/InfiniTime/pull/1869/commits/48a61fba4448b3f9228dd2d01524021f2e542d00 and https://github.com/InfiniTimeOrg/InfiniTime/pull/1869/commits/d9eb1a4215ca6f80889f35d421ccd19e7b435b54 to verify that the RTC backlight is more efficient that'd be super :)

Edit: forgot to rebase to include to include 2042, fixed now. I've updated the above commit refs

[Saarsk]

Nice improvement, this. :) Small note, however.

It might be out of scope for this PR, but I find the spacing to be insufficient for the timeout setting items. It's hard to hit the right one, resulting in me tapping several times until I actually hit the setting I want. :)

There is screen area to space it out a little in both directions, though. It would help a lot. ^^,

[mark9064]

Yeah this is out of scope for this PR - please do open an issue though so the design of this page can be discussed

[JF002]

Hello @mark9064 ! I've just merged #2059 ;)

I also measured the power usage on 48a61fb and d9eb1a4:

48a61fb

• LCD ON (low brightness) : 7.53mA
• Sleep (display OFF) : 420µA
• Always on mode : 3.50mA

d9eb1a4

• LCD ON (low brightness) : 7.53mA
• Sleep (display OFF) : 420µA
• Always on mode : 3.20mA

d9eb1a4 reduces the "always on" power usage by 300µA, which is not insignificant :+1

Could you remind me if there are any other PR that are needed before we can finish review and merging this one?

[mark9064]

I've just rebased to migrate this PR to batched display arguments as well, and to accept the RTC based implementation.

Thanks for the power testing again, you've been brilliant running so many tests over the course of this PR! 300µA takes AOD backlight PWM from 50% to 100% efficiency :) I think that's as good we'll get

All required PRs here are merged

[mark9064]

Small rebase mistake (used old version of a comment)

There are no more technical enhancements I can think of - if people want to try this PR out and feedback now is the time :)

The commits should tell a reasonably coherent story of development. We might want to consider breaking out the brightness message refactor (fix brightness getting stuck high / flashlight brightness restore) but I think it's a simple enough change?

Either way, everything here is ready for review

[KaffeinatedKat]

awesome to see that this pr is finally ready for review

thanks so much to @mark9064, without your help with all the lower level issues this would not have been possible

[JF002]

Thank you very much for you work @mark9064 !

I flashed this branch on my PineTime so I can test it, and I'm pleasantly surprised by the result : the time is well readable in most situation : indoor and even outside if you live in Belgium right now (it's been raining for numerous weeks...).

The battery lasted for 2 days on a single charge (BLE enabled, wake up on double tap on the display), From June 19th to June 22nd :

While it's expected that the always-on display would reduce battery life, 2 full days is a reasonable trade-off

I'll do my best to review this PR ASAP !

[mark9064]

And in real use the screen is off ~8h per night, so 3 days is possible (total runtime 48h as tested above - 16h on per day in real usage - 48/16 = 3)

One thing that's come to mind - should the brightness PWM bits belong in a driver rather than the controller?