Closed martinberlin closed 2 years ago
Could it be the battery pin interfering? The LilyGo has the battery voltage divider connected to GPIO_NUM_36 which is ADC1_CHANNEL_0.
-DBATTERY_ADC_CHANNEL=ADC1_CHANNEL_0
Can be that is somehow bothering this pin but actually EPDiy does not uses pin 36 in V6 config: https://github.com/martinberlin/epdiy-rotation/blob/master/display_ops.h
It has to be something that is stopping EPDiy to install I2C. This are the pins used in V6 PCB
I've pushed up a couple of commits - might want to review them before merging. I'm happy with the rest of the changes.
I've added rtc pullups and pulldowns which should hopefully fix the instant wakeup - on the Lilygo board there are external pullups so we didn't notice this before.
And I've added code to detect when the display rehydrate fails and force a redraw on the epublist. I think this should not be needed when reading as it doesn't assume anything is already on the screen when it draws.
Hi @cgreening pulled your update and tried again with -D BUTONS_ACTIVE_LEVEL=0
It also still deepsleeps for one second and wakes up. I must say that I noticed also that the GPIOs are extreme sensible, even if active level=1 I just get the cable touching (Without even putting high at 3.3 v) and it already presses the button.
I (80882) EPD: Buffer saved 0
I (80882) EPD: Dehydrated EPD
I (80882) SPIFFS: SPIFFS unmounted
I (80882) main: Entering deep sleep
ets Jun 8 2016 00:22:57
rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:7152
load:0x40078000,len:14760
load:0x40080400,len:3728
entry 0x40080678
I (27) boot: ESP-IDF 4.3.0 2nd stage bootloader
I (27) boot: compile time 17:54:59
I (27) boot: chip revision: 1
Good thing is that I can use it active on high, no problem and on LilyGo EPD47 still seems to run correctly.
And I've added code to detect when the display rehydrate fails and force a redraw on the epublist. I think this should not be needed when reading as it doesn't assume anything is already on the screen when it draws.
This also works correctly! Nice update
Let’s stick with the active high then - we can revisit if it starts breaking on another board :)
On Mon, Oct 25, 2021 at 17:01, Martin @.***> wrote:
Hi @cgreening https://github.com/cgreening pulled your update and tried again with -D BUTONS_ACTIVE_LEVEL=0
It also still deepsleeps for one second and wakes up. I must say that I noticed also that the GPIOs are extreme sensible, even if active level=1 I just get the cable touching (Without even putting high at 3.3 v) and it already presses the button.
I (80882) EPD: Buffer saved 0 I (80882) EPD: Dehydrated EPD I (80882) SPIFFS: SPIFFS unmounted I (80882) main: Entering deep sleep ets Jun 8 2016 00:22:57
rst:0x5 (DEEPSLEEP_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT) configsip: 0, SPIWP:0xee clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00 mode:DIO, clock div:2 load:0x3fff0030,len:7152 load:0x40078000,len:14760 load:0x40080400,len:3728 entry 0x40080678 I (27) boot: ESP-IDF 4.3.0 2nd stage bootloader I (27) boot: compile time 17:54:59 I (27) boot: chip revision: 1
Good thing is that I can use it active on high, no problem and on LilyGo EPD47 still seems to run correctly.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/atomic14/diy-esp32-epub-reader/pull/53#issuecomment-951072660, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFMTAAQX2FKL3R7HZGTAJTUIV5M3ANCNFSM5GR6UWGA .
So we can expand the use also to EPDiy supported epapers instead of only LilyGo EPD47
Linked to #52
@cgreening the core of the problem is that EPDiy cannot install I2C driver when using this repository. It does work perfectly when using EPDiy standalone examples. So there must e something in our side that is interfering with EPDiy. I suspected it was touch since it also uses I2C but there is something more than that, basically it fails instantiating the I2C driver.