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.

Sign up for GitHub

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

Jump to bottom

Display upgrades #242

Merged
merged 7 commits into from
Mar 31, 2024
Merged

Display upgrades #242

merged 7 commits into from
Mar 31, 2024

Conversation

DarkZeros
Copy link
Contributor

This PR has commits that affect the display in these aspects:

  • Moves the display init/config/callback from Watchy.cpp to Display.cpp (Where it should be imo)
  • Move the init()/callback to the constructor, no need to call it manually
  • Allows the darkborder feature to be changed on demand using the function, not only on init()
  • Allows to asyncPowerOn() the display, to prepare the HW ahead of time if it will render [-16ms]
  • Remove redundant soft reset after hard reset [-6ms]
  • Reduce init() reset time from 10ms -> 2ms (possibly unsafe? not sure) [-8ms]
  • Change the booster configuration to soft start slower (possibly unsafe? not sure) [-220ms]

In all, this change makes display update take 250ms less (650ms -> 400ms).
Not all of the time saved is power saved, since some of that time the CPU was in light sleep already.
I theoretically computed that the power reduced ~30% (~9mA * 650ms = 6mW -> ~10mA * 400ms = 4mW)

I would value that this change is tested before merging, specially the changes:

  • init() 10ms -> 2ms time
  • Booster configuration

@DarkZeros
Copy link
Contributor Author

DarkZeros commented Jan 8, 2024 •
edited
Loading

Today I managed to test this PR for Power.
I found some inconsistent results so I wouldn't merge it.

Original Watchy v1.0 HW (2.9V) -> ~170uA (650ms per update)
Original Watchy v1.0 HW (2.9V) + PR -> ~190uA (400ms per update)
NOTE: 2.9V is not standard but works (if we do not use WiFi), the ESP CPU needs >1.8V and the Display >2.7V. Using 2.9V bypassing the LDO and saving more power, shouldn't really affect the overall trend of the PR code.

Similar results I found in another board, this needs further examination. Why the reduction in time actually increases power usage. Maybe the booster code uses more power.

@DarkZeros
Move Display specifics
2b21e50 
* Move BusyCallback
* Move constructor pins
@DarkZeros
Refactor Display Init
f2c0c91 
* It makes more sense to put it in the Display class
* The reset should be 2ms, 10ms is worst case
* Also there was a disable call based on display
  that makes more sense to put in the default
  boot switch statement
@DarkZeros
No soft reset after reset
3ce1252 
* Avoid a redundant reset after a reset
  The display is always reset after a hard reset
  and there is no need to re-reset it
@DarkZeros
Set boosters configuration
84c0cd1 
* Reduce the phase on times from 40ms->10ms
* Increase the driving strength, this reduces
  a little the power usage as well
* Reduces 220ms the display update
  -80ms the power on of the display
  -140ms the display partial update
- Note: This may have side effects, but I saw none
  tested on Watchy v1.0, display should be same on
  other Watchy boards
@DarkZeros
Refactor DarkBorder
8103df1 
* Allow to be changed dynamically between
  display updated.
@DarkZeros
Allow AsyncPowerOn
f369b6f 
* The display takes 16ms to power on
  During this time we can render the
  content and finally display it
* The call is optional if we do not call
  it then the old code path is used
* Moved the init to constructor
@DarkZeros
Copy link
Contributor Author

Had some time to measure with a power meter, and updated my PR with proper changes.

  • Modified the delay and strenght parameters of the phases to be as strong as possible and as short as possible. Using the datasheet of SSD1675B (the display controller).
  • Updated the code to be safer, keeping the init() inside the watchy code.
    The PR is now in a mergeable state.
    These are the measurements of Energy/Power:
    image

I am not sure why the ESP reported times don't match the times in the capture graph, maybe the ESP reports the power off comand and the display does some extra stuff using power.
Anyway, it is clear that the Booster configuration uses less power during the "flat" phase.
The reset reduction and async make the startup be much faster, and the delay reduction make the display also faster.

Power wise this PR condenses the power usage in a smaller period of time, but reduces the total Energy.
From 1.39uAh to 1.18uAh per update (-15% power).

@DarkZeros
Copy link
Contributor Author

I will continue investigating other things like:

  • Strange power spike on powerOn
  • LUT configuration for an even faster update
  • Power off seems costly

@DarkZeros
Remove delay after hard reset
be185cb 
* Implemented by overloading the
  virtual method _reset() in GxEPD2_EPD
* Tested to write straight away
  and works ok. Seems unnecessary.
* 10ms might look like little but the
  ESP is not sleeping and CPUs are on.
  This is probably using 0.1 uAh
  (10% of display update total cost)
@DarkZeros
Copy link
Contributor Author

DarkZeros commented Jan 19, 2024 •
edited
Loading

Last change removes a redundant 10ms delay after the hard reset.
Current PR gives:

Time: 471 ms
Energy: 1.09 uAh
Average Power: 30.8 mW
Average Current: 8.33 mA

-21% energy usage compared to master.

@sqfmi sqfmi merged commit be185cb into sqfmi:master Mar 31, 2024
@sqfmi
Copy link
Owner

sqfmi commented Mar 31, 2024

Amazing work!!! Apologies it took so long to merge, thank you !!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@DarkZeros @sqfmi