search

Passific / m5paper_esphome

Repository for ESPHOME components for m5paper
28 stars 3 forks source link

Touchscreen not working during display update #3

Open bbadrignans opened 5 months ago

bbadrignans commented 5 months ago

Thank you very much for this work.

I notice that during display update (that is quite long : ~5 seconds), touchscreen events are not working.

Do you think it is due to it8951e driver ? Or the way the yaml example is written ?

Do you know a way to speed up this update time ? Maybe increasing SPI clock ? Optimizing driver ?

Also I notice a glitch on the screen during update (colour inversion), maybe it is part of the issue.

Passific commented 5 months ago

Hello,

From my experience, only the first refresh is long and takes 2s. Then all screen updates take only 200ms!

For the touchscreen, as the first refresh is done during init phase, I did not try to use the touchscreen. But not been able to use the screen for 200ms during further refreshes may be due to ESPHome beeing executed on a single event chain.

I don't have access to my M5Paper for the moment, so I cannot test much more than that...

Also, color inversion is a normal process for e-paper screens. It help prevent artefacts of previous images.

bbadrignans commented 5 months ago

Thank you for your answer. You are right for the single event chain.

Looking to logs it takes 6-7 seconds on my device. The log Pin busy timeout appears every 2 minutes, strange. During this time touchscreen does not work.

Removing the graph reduce the hang time to about 3 seconds.

Maybe an issue with my device. I use esphome version 2024.3.1.

I will try to understand what happens.

[22:42:00][D][sensor:094]: 'Test status screen humidity': Sending state 57.09926 % with 1 decimals of accuracy
[22:42:07][E][it8951e.display:123]: Pin busy timeout
[22:42:07][E][it8951e.display:123]: Pin busy timeout
[22:42:07][W][component:232]: Component time took a long time for an operation (7070 ms).
[22:42:07][W][component:233]: Components should block for at most 30 ms.
[...]
[22:43:00][I][cal:542]: x=408, y=374, x_raw=230, y_raw=666
[22:43:00][I][cal:542]: x=405, y=374, x_raw=228, y_raw=666
[22:43:07][W][component:232]: Component time took a long time for an operation (6870 ms).
[22:43:07][W][component:233]: Components should block for at most 30 ms.
[...]
[22:44:00][D][sensor:094]: 'Test status screen humidity': Sending state 56.88564 % with 1 decimals of accuracy
[22:44:07][E][it8951e.display:123]: Pin busy timeout
[22:44:07][E][it8951e.display:123]: Pin busy timeout
[22:44:07][W][component:232]: Component time took a long time for an operation (7067 ms).
[22:44:07][W][component:233]: Components should block for at most 30 ms.
Passific commented 5 months ago

Ok I see, I though the display was taking 7s to draw, but from the logs it looks more like the lambda is taking this time to generate the image to display.

I guess this is only related to the CPU power you have on the device and the number/complexity of elements you are displaying.

Try to have a less complex lambda, is the touchscreen more responsive?

On my side, lambda computation takes 2 to 3 seconds, then the screen takes 200ms to refresh. I also have the Pin busy timeout log on a regular basis, without any spotted side effects.

bbadrignans commented 4 months ago

You are right, it is the lambda that takes time. The example you give is quite complex, I used quite the same.

This slowness is not a real issue with your example, but it is if one tries to use touchscreen.

To add more complexity, I tried to add lvgl in esphome : https://github.com/lukasz-tuz/esphome-gui/ It compiles and quite works :

I think that the it8951 driver has issues. Do you know where it originally comes from ? Is it inspired by https://github.com/m5stack/M5EPD/blob/main/src/M5EPD_Driver.cpp ?

ZeFish commented 1 week ago

Actually trying to make a wall panel for HA with esphome lvgl and I'm also having those pin busy log and then reboot. For now I juste have a button on the screen.

Not sure what do to, is there a way to increase the timeout? I don't know if that can help, but here's a sample log

[15:36:04][E][it8951e.display:140]: SPI busy timeout 3
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:05][E][it8951e.display:123]: Pin busy timeout
[15:36:06][E][it8951e.display:123]: Pin busy timeout
[15:36:06][E][it8951e.display:123]: Pin busy timeout
[15:36:06][E][it8951e.display:123]: Pin busy timeout
[15:36:06][E][it8951e.display:123]: Pin busy timeout
[15:36:06][E][it8951e.display:123]: Pin busy timeout
[15:36:06]E (89016) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time:
[15:36:06]E (89016) task_wdt:  - loopTask (CPU 1)
[15:36:06]E (89016) task_wdt: Tasks currently running:
[15:36:06]E (89016) task_wdt: CPU 0: IDLE
[15:36:06]E (89016) task_wdt: CPU 1: loopTask
[15:36:06]E (89016) task_wdt: Aborting.
[15:36:06]
[15:36:06]abort() was called at PC 0x40118294 on core 0
[15:36:06]
[15:36:06]
[15:36:06]Backtrace:0x40083df5:0x3ffbeabc |<-CORRUPTED
WARNING Found stack trace! Trying to decode it
WARNING Decoded 0x40083df5: panic_abort at /Users/ficeto/Desktop/ESP32/ESP32S2/esp-idf-public/components/esp_system/panic.c:402
[15:36:06]
[15:36:06]
[15:36:06]
[15:36:06]
[15:36:06]ELF file SHA256: 0000000000000000
[15:36:06]
[15:36:06]Rebooting...
ZeFish commented 1 week ago

This fork resolves some but not all the issue with busy pin https://github.com/timit3-github/m5paper_esphome