vroland / epdiy

EPDiy is a driver board for affordable e-Paper (or E-ink) displays.
https://vroland.github.io/epdiy-hardware/
GNU Lesser General Public License v3.0
1.32k stars 184 forks source link

Will epdiy support Power-Management of ESP? #255

Closed lanistor closed 1 year ago

lanistor commented 1 year ago

When open Power Management, then painting will have weird behavior (paint on wrong area, blurry image), even set CPU frequency to 240MHz (use ESP_PM_CPU_FREQ_MAX lock mode).

martinberlin commented 1 year ago

I don't think implementing of PM has to be done in this library but rather on the Firmware that implements this library. Basically epdiy already takes care of consuming the minimum possible letting the user do an epd_poweroff() right after refreshing the display switching all high voltages off.

When open Power Management, then painting will have weird behavior (paint on wrong area, blurry image), even set CPU frequency to 240MHz

Reading the documentation says: Enabling power management features comes at the cost of increased interrupt latency. Extra latency depends on a number of factors, such as the CPU frequency, single/dual core mode, whether or not frequency switch needs to be done.

This sounds to me like they are adding locks in some parts which will add latency. And that will not play well with this component.

Power Management if used should be at the highest CPU level when epdiy is transmitting when possible and then when it's not communicating with the display can be set to lower values. If you already tried this and does not work as expected is because either is not correctly setup or the settings are adding latency in the parallel communication affecting how the data arrives to the display.

Now if this would be considered at any point is not for me to decide but rather vroland that is the project owner.

lanistor commented 1 year ago

Power Management if used should be at the highest CPU level when epdiy is transmitting when possible and then when it's not communicating with the display can be set to lower values. If you already tried this and does not work as expected is because either is not correctly setup or the settings are adding latency in the parallel communication affecting how the data arrives to the display.

Yeah, i did as this, the CPU frequency is 240MHz, and the APB frequency is 80MHz, both same as disabled PM(Power Management), but the painting still have error.

Just enable PM by check Component config - Power Management - Support for power management, don't check Enable dynamic frequency scaling (DFS) at startup, and don't add any PM code in demo of epdiy, this condition, PM will not run, and all frequency (CPU, APB) will be same as before (by esp_clk_cpu_freq, esp_clk_apb_freq), but the painting will like this (demo code on v6): Besides, the painting speed will be slower, and painting intervals will become longer.

I wan't to close PM before painting, and open PM (open PM means: automatic frequency reduction and modem-sleep mode) after painting, but this behavior seems epdiy rely on some code affected by PM macro definition (CONFIG_PM_ENABLE), so you cannot enable Power Management if using epdiy at all. I want to find the code out but i cannot, so i don't know how to change.

Here is the videos i recorded on v6 board: Video1, Video2, Video3, v5 has the same behavior.

vroland commented 1 year ago

Hm, it seems plausible that the power management interferes with interrupt timing and possibly RMT clocks. It may be a small fix, but it also may take a lot of fiddling with the timing. Since for many people, "Power Management" will be just going to deep sleep, I'd rather focus on getting the V7 firmware done for now. There is probably a way to make it work together, I just can't estimate the development time needed...

lanistor commented 1 year ago

Agree to deal with v7 first, this is a great project.

I think Power Management is not only for sleeping, if just for sleeping to save power, we can use normal sleep mode , but this will stop WiFi connection, and reconnect again when wake up, but this may take more than 10 seconds and give users a poor experience.

PM can fall to sleep with maintaining WiFi connection, i think it's a good solution for scenes those need both network and low power consumption.

I'm connecting with developers at Espressif company for this, i will share all messages once i got some.

martinberlin commented 1 year ago

PM can fall to sleep with maintaining WiFi connection, i think it's a good solution for scenes those need both network and low power consumption.

This will be something new for me. It would be rather difficult that the micro-controller sleeps while maintaining any kind of Radio connectivity. It's precisely WiFi what has more consumption than anything else in this MCUs. In the document says:

WiFi: between calls to esp_wifi_start() and esp_wifi_stop(). If modem sleep is enabled, the lock will be released for the periods of time when radio is disabled.

But in any moments mentions that sleeps while WiFi is connected. It might sleep just when Radio is off adding this locks that mentions automatically.

lanistor commented 1 year ago

I found this in the Sleep modes document:

If Wi-Fi/Bluetooth connections need to be maintained, enable Wi-Fi/Bluetooth Modem-sleep mode and automatic Light-sleep feature (see Power Management APIs). This allows the system to wake up from sleep automatically when required by the Wi-Fi/Bluetooth driver, thereby maintaining the connection.

And espressif seems also did other things to save power, works with this Modem-sleep mode.

vroland commented 1 year ago

Also, making this compatible with light-sleep or active wifi connection and clock down would make the component more robust and eliminate a source of errors for users. It's likely that the actual required changeset would be quite small, but the associated research maybe not.

lanistor commented 1 year ago

@vroland As i tested, the v7 board can work with Power Management by PM-Lock perfectly, the painting will be normal by the below code:

#if CONFIG_PM_ENABLE
#if CONFIG_IDF_TARGET_ESP32
  esp_pm_config_esp32_t pm_config = {
#elif CONFIG_IDF_TARGET_ESP32S2
  esp_pm_config_esp32s2_t pm_config = {
#elif CONFIG_IDF_TARGET_ESP32C3
  esp_pm_config_esp32c3_t pm_config = {
#elif CONFIG_IDF_TARGET_ESP32S3
  esp_pm_config_esp32s3_t pm_config = {
#endif
    .max_freq_mhz = CONFIG_ESP32_DEFAULT_CPU_FREQ_MHZ,
    .min_freq_mhz = 80,
#if CONFIG_FREERTOS_USE_TICKLESS_IDLE
    .light_sleep_enable = false // or `true` is ok
#endif
  };
  ESP_ERROR_CHECK(esp_pm_configure(&pm_config));
#endif // CONFIG_PM_ENABLE

// Below for updating screen

static esp_pm_lock_handle_t rmt_send_task_pm_lock;

#if CONFIG_PM_ENABLE
  // Add PM-Lock before painting
  static esp_pm_lock_handle_t rmt_send_task_pm_lock;
  ESP_ERROR_CHECK(esp_pm_lock_create(ESP_PM_CPU_FREQ_MAX, 0, "rmt_send_task",
                                     &rmt_send_task_pm_lock));
  ESP_ERROR_CHECK(esp_pm_lock_acquire(rmt_send_task_pm_lock));
#endif // CONFIG_PM_ENABLE

  epd_poweron();
  epd_hl_update_area(&hl, updateMode, temperature, update_area);
  epd_poweroff();

#if CONFIG_PM_ENABLE
  // release PM-Lock after painting
  ESP_ERROR_CHECK(esp_pm_lock_release(rmt_send_task_pm_lock));
#endif // CONFIG_PM_ENABLE

But the v5, v6 board will painting with error like this: The PM-Lock has no effect on the board. And i contacted with developers at Espressif company, they had tested for MCU and said the PM-Lock has no problems on ESP32.

So what will be the problem? I have no idea.

lanistor commented 1 year ago

Finally i found a way to resolve this problem on v5, v6 board: Set the frequency to 160MHz instead of 240MHz.

I don't know why this can make the PM-Lock work, v7 board doesn't need to do this. Is this a problem of ESP32 or epdiy?

And another question: will this change slow down the speed of painting?

lanistor commented 1 year ago

Unfortunately, i tested LCD screen with a developement board of ESP32-WROVER-B, it can run perfectly with PM and PM-Lock, and in all CPU frequency, so it's hard to communicate with developers at Espressif company for this problem.

martinberlin commented 1 year ago

The drawing speed difference will be minimal and almost no noticiable. Also running at a lower CPU speed the consumption will be lower. Good work finding a solution for the v5 board!

lanistor commented 1 year ago

Got it, thanks.