Adding Lilygo ESP32S3 Platform Support

[THSLP13]

A new board from Lilygo published.

It uses ESP32S3(N16R8) as controller,and uses ED047TC1(Soft ver.) as display.

I try to make a patch to my own code,but arduino IDE only throws a lot of(99+) error to me.
When I simply compile code from your example,IDE throws errors again,and throws the same errors.
So I write the issue.

The code from Xinyuan-LilyGO works normal and fully functional,but they hasn't update their code such as update mode,they just update the pinmap and I2S Sources.
(Hint:Select S3 branch to get S3 version driver from lilyGo)

Most errors contains declaration error.
Please notice me if you need further information about this problem.

[martinberlin]

Sorry but you started wrong, because there is a PR #180 that is still not merged, that will enable EPDiy to compile in IDF v 5.0
Until that is merged, you should start on that branch, instead of EPDiy master since it's not ready for that version of IDF.
I was going to make my own PR to add this board but if you manage to do it, go ahead.

[martinberlin]

@THSLP13 since it's on your own best interest to have this working on Arduino, please help me test this PR:

#180 (comment)
So you can give some feedback about it. Just get that PR branch and use it to compile your EPDiy library on Arduino IDE.

[THSLP13]

@THSLP13 since it's on your own best interest to have this working on Arduino, please help me test this PR:

#180 (comment) So you can give some feedback about it. Just get that PR branch and use it to compile your EPDiy library on Arduino IDE.

Hi,thanks for your reply.
Due to my coding skill level I couldn't give much advice,but I will do my best to test the PR.

[martinberlin]

When my Lilygo S3 arrives I will try to port the updates over the existing working branch on IDF v5.

I started on my fork but is very raw still and needs to be debugged.

[vroland]

I'm curious how the S3-based board will perform. I have some normal S3 dev boards on the way since the Lilygo board is a bit expensive and not flexible enough for prototyping, but I'm confident @martinberlin can make the necessary changes :)
Since we're planning an S3-based epdiy for the future, this will be good ground work anyway.

[martinberlin]

@THSLP13 you can try this:

https://github.com/martinberlin/epdiy-rotation/tree/lilygos3

Just checkout the lilygos3 branch. Note that it will work only with ESP-IDF ver. 5-beta1
So far I only tried the dragon. Some statistics:

update_screen() 957 ms to draw dragon  on ESP32
update_screen() 2176 ms to do the same in LilyGo S3

It's much slower. I don't know if it would be possible to improve that (Measured with CPU at 240Mhz, is not related to CPU, is the esp_lcd data speed)

[vroland]

@martinberlin Using the LCD peripheral to output each line separately probably also adds a lot of overhead. I'll be back at home where I have my oscilloscope in ~10 days and by then my S3 boards will hopefully have arrived, so I can do some experiments.
It would be nice to just start one LCD transaction per frame and control the remaining signals via interrupts / external logic. That would probably be the fastest way to do this.

[vroland]

Nice work though for porting to esp_lcd as a prototype :) Did you try higher pixel clocks and did that make a difference?

[martinberlin]

Nice work though for porting to esp_lcd as a prototype :) Did you try higher pixel clocks and did that make a difference?

Thanks Valentin but in fact I just cleaned up Lilygo's take on this and adapted it to the latest version. I tried different clocks including the fastest one as described here in esp_lcd docs. Note that the 240Khz that uses PLL_D2 drops a lcd_i80_select_periph_clock(490): unsupported clock source: 7
With the fastest clock source that I could use: LCD_CLK_SRC_PLL160M (using pclk_hz at 50 * 1000 * 1000)

The dragon takes: update_screen() 1620 ms -> to be drawn. Still high but better than 2 seconds.

It would be nice to just start one LCD transaction per frame and control the remaining signals via interrupts / external logic. That would probably be the fastest way to do this.

Yes that is a great idea. In my opinion this is slower because in the older version you filled a buffer while sending the other. But this one uses just 1 so it's like double slow. I'm quite sure that well optimized can be some good percentage faster with S3 that is at least 15% faster and maybe has a faster PSRAM also. But we cannot confirm it till someone tries that for real. If that is possible then a new board with S3 makes great sense for big panels.

On other rants that crossed my head using this board: What makes me crazy about this new Lilygo S3 board is that they did something weird with the Serial. A flash monitor often delivers:
E (204) esp_image: invalid segment length 0xffffffff
E (205) boot: Factory app partition is not bootable

And you have to flash it 2 times in order to get the new program flashed. This and the fact that after 2 days of using it has a dead row make me discard this as anything that will use on the future, even though is a great info for us Lilygo going forward with this new MCU, so we can make a powerful S3 board and they are proven IOs that work.

[martinberlin]

Attention: Additional weirdness found in this LilygoS3 device:

This is my BLE receive JPG demo. Just an experimental receive and decode JPG that is too slow to be anything useful (100Kb in about 30 seconds, but hey consumes less than WiFi)
Well here I was having a lot of weird resets due to Brownout detector. So I connected my Nordic PPK power kit to check out what is going on.

And what I found is this:
If you toggle epd_poweron() / off() just to make short updates, that generates a spike of about 600mA that is what makes this device reset. It triggers mostly when you use BLE or WiFi, meaning for me that there is something badly designed, because in the old one I never had this resets.
And this is BLE, so it consumes a fraction of WiFi, and still generates a 600mA (or more) spike when you do an epd_poweron() that of course means immediate reset on USB since the PC can deliver only 500mA.
So check my last commit to see how I had to remove this in order to make it work. Here in more detail:

Still in my humble opinion, this is a highly experimental device, that I won't think even remotely to use in any real-life project. Is a pity, because the idea is good, and has SD card and an RTC on board. A lot of goodies, but this failures make it really untrustworthy.

Short video explanation

To discard that is my part of porting this to the new version of EPDiy I just ran their code with a simple program that does only this in arduino-esp32:

void loop() {
  epd_poweron();
  epd_clear();
  epd_poweroff();
  delay(1000);
}

No Wifi, or BLE, just that and this is the result:

About 294 mA spikes every time epd_poweron() triggers the HV pumps (Or what is that otherwise)
But if you use this with WiFi or BLE then it sums up to the other consumption making that huge spike that surpasses 500mA and that's the real problem. Apart that it resets it will eat your battery like cookies!

[vroland]

Damn, that sounds bad. Is the lilygo board still using the LT1945-based power generation? I think epdiy v5 had a rather high inrush current as well, but the TPS65185 in v6 should not have this problem. In a way, it's good to have them do some mistakes, so we can learn from them and avoid them ;)

Regarding the clock speed: If we can get DMA working and fill the buffer while the LCD peripheral is feeding the EPD, a clock speed of ~30MHz should be sufficient for all EPDs i've checked. Maybe 35MHz if we account for some overhead. So the trick will be in efficiently using DMA and both cores of the ESP.

I'm currently thinking of the following architecture:
Run the LCD peripheral continuously and use the bounce buffer method, where an interrupt is called to re-fill the LCD peripheral buffer.
Then, we start with the difference buffer in PSRAM as in epdiy. We have an additional queue / buffer of lines ready for output in SRAM. Two tasks for both cores of the ESP32 run continuously and fill the line queue in SRAM by performing the waveform lookup on the difference buffer / framebuffer. Every time the LCD peripheral buffer runs low, it calls an interrupt to fill its bounce buffer. In that interrupt, we fetch lines from the line buffer and put them in the LCD peripheral buffer.
This does not use DMA, but probably has the lowest latency.
Alternatively, we could have two framebuffers in PSRAM instead of having a line buffer in SRAM. We fill one framebuffer with the two CPU tasks while the other is written out by the LCD peripheral using DMA. This uses less CPU resources but requires a write-back to PSRAM, which may or may not be slower. An it adds one frame = ~12ms delay. But if the first method does not work out it is worth a try, since memory bandwith in the ESP32-S3 is much higher than in the ESP32.

[martinberlin]

Hi Valentin,

Is the lilygo board still using the LT1945-based power generation?

Yes they are still using them: U2 ( Schematics )
But I think they made some modifications on this board because the other one had no this spikes. Maybe a smaller capacitor, no idea since I'm not familiar with the older PCB versions like you ;)
About the ideas, they sound great!
Would love to follow them and test how they perform.
By the way I've got a full refund for this board and I have no use for it at all, so if you want to have one to experiment, is all yours.
I would love to see a design based on S3, I think the ESP32-S3-WROOM-1(N8R2) with 2MB PSRAM would suffice (Still about 190 available)

[vroland]

I think the S3 dev board will probably arrive before your lilygo board, so I'm not sure if it's worth it. Once we have our own board it will (hopefully) be obsolete anyway ;) But if you really don't need it / want it it could be useful as a backup :)
Regarding the module: My dev kit will be N8R8 and if I remember correctly, there is a difference in how the PSRAM is connected on some modules. I.e., some modules support octal SPI and some don't. So in case we go with the double framebuffer in PSRAM method, having the higher bandwith is probably nice. So let's see what we need, hopefully JLCPCB will have more stock soon anyway, since the S3 is relatively new.

[lbuque]

Attention: Additional weirdness found in this LilygoS3 device:

This is my BLE receive JPG demo. Just an experimental receive and decode JPG that is too slow to be anything useful (100Kb in about 30 seconds, but hey consumes less than WiFi) Well here I was having a lot of weird resets due to Brownout detector. So I connected my Nordic PPK power kit to check out what is going on.

And what I found is this: If you toggle epd_poweron() / off() just to make short updates, that generates a spike of about 600mA that is what makes this device reset. It triggers mostly when you use BLE or WiFi, meaning for me that there is something badly designed, because in the old one I never had this resets. And this is BLE, so it consumes a fraction of WiFi, and still generates a 600mA (or more) spike when you do an epd_poweron() that of course means immediate reset on USB since the PC can deliver only 500mA. So check my last commit to see how I had to remove this in order to make it work. Here in more detail:

Still in my humble opinion, this is a highly experimental device, that I won't think even remotely to use in any real-life project. Is a pity, because the idea is good, and has SD card and an RTC on board. A lot of goodies, but this failures make it really untrustworthy.

Short video explanation

To discard that is my part of porting this to the new version of EPDiy I just ran their code with a simple program that does only this in arduino-esp32:

void loop() {
  epd_poweron();
  epd_clear();
  epd_poweroff();
  delay(1000);
}

No Wifi, or BLE, just that and this is the result:

About 294 mA spikes every time epd_poweron() triggers the HV pumps (Or what is that otherwise) But if you use this with WiFi or BLE then it sums up to the other consumption making that huge spike that surpasses 500mA and that's the real problem. Apart that it resets it will eat your battery like cookies!

Here are our test results:

The test code is:

https://github.com/Xinyuan-LilyGO/LilyGo-EPD47/tree/perfect-refresh/examples/drawImages

The full refresh time is about 450ms.

[lbuque]

I think double buffering, the improvement may be less than 5%, because the current method only takes some more copy time than buffering, which is almost negligible.

[martinberlin]

My test was after being ported to EPDiy using IDF v5.

update_screen() 957 ms to draw dragon  on ESP32
update_screen() 2176 ms to do the same in LilyGo S3 -> Could get it down to around 1600 ms. updating some settings.

The full refresh time is about 450ms.

Yes sure, but that's after receiving the framebuffer, when it starts rendering!
I'm talking about what happens before: The sending of the full framebuffer bytes, that is 960*540/2 (259200 bytes using 4 bit pixels)

That is the update_screen() which is sending the parallel data. Note that this version supports Waveforms, I don't have any idea if that can add more time, maybe Valentin can tell more about that.
What I know is that in my tests this S3 version is definitively slower than the old one using EPDiy as a controller. Now if this new version of EPDiy component is itself slower than the one that you are using I don't know, but I could not replicate with other epapers.

About the spikes in consumption in epd_poweron() @liangyingy you should take a look for yourself. This will reset the device if it's using while other consuming things are taking place, like WiFi or BLE. And in my humble opinion, this makes your S3 device hardly usable, if you need to draw stuff while downloading an image.
The workaround is to leave the epaper on at all time, if you need to draw a progress bar, something that is unwise if you make something that is battery powered.
The last device you designed based on ESP32-WROVER has not this problem. And works stable with all examples, while this new one does not, I had to modify the BLE example and left it with epd_poweron() all the time in order to render the image.

But don't take me wrong here: I like a lot the hardware on the device, it cames with goodies like RTC on board, Raspberry Pi connector and more. I'm just criticizing it objectively from a user point of view, precisely because I want to use it for something.

[lbuque]

We should have a unified interpretation of the concept of full refresh.

The full refresh time I think is the time it takes to call epd_hl_update_screen or epd_draw_image.

[lbuque]

There is a reset problem using ble or wifi, is it found by which code test? We want to reproduce this bug.

[martinberlin]

Hi Liang,
sure I agree with this point.
You can find my BLE example here:

https://github.com/martinberlin/epdiy-rotation/tree/lilygos3
pull that repository.

 git clone --branch lilygos3 https://github.com/martinberlin/epdiy-rotation.git

It's on examples/ble-image
I'm sure it can be ported to Arduino esp32 pretty easily.

Here you can find an article I wrote about BLE receive JPG.
As BLE client to send the image you can use my service: https://cale.es
I can create an account for you if you wish with the right screen and a demo image gallery. Then you just need to build and flash the ble-image Firmware.
This will work now in S3 since I added some ifdef pre-compiler conditions, to avoid doing epd_poweroff() in your device.
Just tell me if you need help, I can also try to port it to arduino-esp32, and make a pull request in your Repository.

[lbuque]

@martinberlin

I ran ble-image on both boards and no device reset occurred.

The current is about 250ma.

[martinberlin]

It occurs only when it receives data. When it's idle of course does not consume.
Note that I also commented the epd_poweoff() just for your board since the spike comes when is in off state and it's triggered to on while receiving data.
Try to leave the power on /off and send some data using cale.es as a client with Chrome browser and you will see what I mean.
It happens exactly when receiving data and the progress bar is drawn. The reset triggers only in the S3 board not on the other (or very rarely)

If you want I can prepare an account for you with the right configuration and image gallery so you can log in and try it right away. My email is on my GitHub profile

[lbuque]

The above test result is to use https://cale.es/ to send the image to the device through ble.

[martinberlin]

Great. But did you tried to remove my ifdef pre-processor directives so it does an epd_poweron() / epd_poweroff()

Try to change here:

void epaper_power_off() {
    #ifndef CONFIG_EPD_BOARD_REVISION_LILYGO_S3_47
      epd_poweroff();
    #endif
}

That function wrapper I did just to avoid switching power on /off and avoid the reset. Just leave it with the epd_poweroff() and try to receive the image again. By the way if you want to add a BLE receive image example feel free to use it also in your own repository. I can share also the backend part that converts the JPG into HEX bytes.

[lbuque]

@martinberlin

You can apply the following patch and run it on your device if there is still a device reset issue:

Please add the following patch to epdiy-rotation:

diff --git a/examples/ble-image/main/gatt_server_receive.cpp b/examples/ble-image/main/gatt_server_receive.cpp
index d38744c..1357820 100644
--- a/examples/ble-image/main/gatt_server_receive.cpp
+++ b/examples/ble-image/main/gatt_server_receive.cpp
@@ -222,9 +222,9 @@ extern "C"
  *        That means you cannot turn on -> draw something fast -> turn off or you will have a Reset
  */
 void epaper_power_off() {
-    #ifndef CONFIG_EPD_BOARD_REVISION_LILYGO_S3_47
+    // #ifndef CONFIG_EPD_BOARD_REVISION_LILYGO_S3_47
       epd_poweroff();
-    #endif
+    // #endif
 }
 
 void progressBar(long processed, long total)
@@ -303,7 +303,7 @@ int decodeJpeg(uint8_t *source_buf, int xpos, int ypos) {
     if (jpeg.decodeDither(dither_space, 0))
       {
         time_decomp = (esp_timer_get_time() - decode_start)/1000 - time_render;
-        ESP_LOGI("decode", "%d ms - %dx%d image MCUs:%d", time_decomp, jpeg.getWidth(), jpeg.getHeight(), mcu_count);
+        ESP_LOGI("decode", "%ld ms - %dx%d image MCUs:%d", time_decomp, jpeg.getWidth(), jpeg.getHeight(), mcu_count);
       } else {
         ESP_LOGE("jpeg.decode", "Failed with error: %d", jpeg.getLastError());
       }
@@ -489,7 +489,7 @@ static void gatts_profile_a_event_handler(esp_gatts_cb_event_t event, esp_gatt_i
     }
     case ESP_GATTS_READ_EVT: 
     {
-        ESP_LOGI(GATTS_TAG, "GATT_READ_EVT, conn_id %d, trans_id %d, handle %d\n", param->read.conn_id, param->read.trans_id, param->read.handle);
+        ESP_LOGI(GATTS_TAG, "GATT_READ_EVT, conn_id %d, trans_id %ld, handle %d\n", param->read.conn_id, param->read.trans_id, param->read.handle);
         esp_gatt_rsp_t rsp;
         memset(&rsp, 0, sizeof(esp_gatt_rsp_t));
         rsp.attr_value.handle = param->read.handle;
@@ -518,7 +518,7 @@ static void gatts_profile_a_event_handler(esp_gatts_cb_event_t event, esp_gatt_i
                 (param->write.value[2] << 8) +
                 (param->write.value[3] << 16) +
                 (param->write.value[4] << 24);
-                ESP_LOGI(GATTS_TAG, "0x01 content-lenght received:%d", received_length);
+                ESP_LOGI(GATTS_TAG, "0x01 content-lenght received:%ld", received_length);
 
                 esp_log_buffer_hex(GATTS_TAG, param->write.value, param->write.len);
             }
@@ -531,8 +531,8 @@ static void gatts_profile_a_event_handler(esp_gatts_cb_event_t event, esp_gatt_i
                 time_receive = (esp_timer_get_time()-start_time)/1000;
                 decodeJpeg(source_buf, 0, 0);
 
-                ESP_LOGI("ble-rec", "%d ms - download", time_receive);
-                ESP_LOGI("render", "%d ms - copying pix (JPEG_CPY_FRAMEBUFFER:%d)", time_render, JPEG_CPY_FRAMEBUFFER);
+                ESP_LOGI("ble-rec", "%ld ms - download", time_receive);
+                ESP_LOGI("render", "%ld ms - copying pix (JPEG_CPY_FRAMEBUFFER:%d)", time_render, JPEG_CPY_FRAMEBUFFER);
 
                 epd_poweron();
                 epd_hl_update_screen(&hl, MODE_GC16, temperature);
@@ -546,7 +546,7 @@ static void gatts_profile_a_event_handler(esp_gatts_cb_event_t event, esp_gatt_i
                 memcpy(&source_buf[img_buf_pos], param->write.value, param->write.len);
                 img_buf_pos += param->write.len;
 
-                ESP_LOGI(GATTS_TAG, "GATT_WRITE_EVT, value len %d, total:%d", param->write.len, img_buf_pos);
+                ESP_LOGI(GATTS_TAG, "GATT_WRITE_EVT, value len %d, total:%ld", param->write.len, img_buf_pos);
             }
 
             // Debug received bytes
diff --git a/src/epd_driver/board/epd_board_lilygo_s3_47.c b/src/epd_driver/board/epd_board_lilygo_s3_47.c
index d71e1f7..57089d1 100644
--- a/src/epd_driver/board/epd_board_lilygo_s3_47.c
+++ b/src/epd_driver/board/epd_board_lilygo_s3_47.c
@@ -27,13 +27,14 @@
 /* Edges */
 #define CKH GPIO_NUM_41
 
-typedef struct {
+typedef struct
+{
+  bool ep_latch_enable : 1;
   bool power_disable : 1;
   bool pos_power_enable : 1;
   bool neg_power_enable : 1;
-  bool ep_scan_direction : 1;
-  bool ep_latch_enable : 1;
   bool ep_stv : 1;
+  bool ep_scan_direction : 1;
   bool ep_mode : 1;
   bool ep_output_enable : 1;
 } epd_config_register_t;
@@ -98,8 +99,7 @@ static void epd_board_init(uint32_t epd_row_width) {
   PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[CFG_DATA], PIN_FUNC_GPIO);
   PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[CFG_CLK], PIN_FUNC_GPIO);
   PIN_FUNC_SELECT(GPIO_PIN_MUX_REG[CFG_STR], PIN_FUNC_GPIO);
- 
-  
+
   fast_gpio_set_lo(CFG_STR);
 
   config_reg.ep_latch_enable = false;
@@ -160,20 +160,6 @@ static void epd_board_poweron(epd_ctrl_state_t *state) {
     fast_gpio_set_hi(STH);
 }
 
-void epd_powerdown_lilygo_t5_47() {
-    config_reg.pos_power_enable = false;
-    push_cfg(&config_reg);
-    busy_delay(10 * 240);
-    config_reg.neg_power_enable = false;
-    push_cfg(&config_reg);
-    busy_delay(100 * 240);
-    config_reg.power_disable = true;
-    push_cfg(&config_reg);
-
-    config_reg.ep_stv = false;
-    push_cfg(&config_reg);
-}
-
 static void epd_board_poweroff_common(epd_ctrl_state_t *state) {
   // POWEROFF
   epd_ctrl_state_t mask = {  // Trigger output to shift register
@@ -203,8 +189,17 @@ static void epd_board_poweroff_common(epd_ctrl_state_t *state) {
 
 static void epd_board_poweroff(epd_ctrl_state_t *state) {
   // This was re-purposed as power enable.
-  config_reg.ep_scan_direction = false;
-  epd_board_poweroff_common(state);
+  config_reg.pos_power_enable = false;
+  push_cfg(&config_reg);
+  busy_delay(10 * 240);
+  config_reg.neg_power_enable = false;
+  push_cfg(&config_reg);
+  busy_delay(100 * 240);
+  config_reg.power_disable = true;
+  push_cfg(&config_reg);
+
+  config_reg.ep_stv = false;
+  push_cfg(&config_reg);
 }
 
 static void epd_board_poweroff_touch(epd_ctrl_state_t *state) {
diff --git a/src/epd_driver/i2s_data_bus_s3.c b/src/epd_driver/i2s_data_bus_s3.c
index 48b0b8f..7910f5b 100644
--- a/src/epd_driver/i2s_data_bus_s3.c
+++ b/src/epd_driver/i2s_data_bus_s3.c
@@ -53,7 +53,7 @@ static bool notify_trans_done(esp_lcd_panel_io_handle_t panel_io, esp_lcd_panel_
 
 void i2s_bus_init(i2s_bus_config *cfg)
 {
-    ESP_LOGI(TAG, "Initialize Intel 8080 bus\n6:%d 7:%d 4:%d 5:%d 2:%d 3:%d 0:%d 1:%d\nstart_pulse:%d clock:%d\nepd_row_width:%d",
+    ESP_LOGI(TAG, "Initialize Intel 8080 bus\n6:%d 7:%d 4:%d 5:%d 2:%d 3:%d 0:%d 1:%d\nstart_pulse:%d clock:%d\nepd_row_width:%ld",
     cfg->data_6,cfg->data_7,cfg->data_4,cfg->data_5,cfg->data_2,cfg->data_3,cfg->data_0,
     cfg->data_1, cfg->start_pulse, cfg->clock, cfg->epd_row_width);
 

Here is the current when rendered (at the red arrow):

[martinberlin]

Nice catch 👍
I will try this morning, report how it works, and leave that change ready so we can merge this new board in epdiy. Thanks for your time!

[vroland]

Adding support for their board should be straightforward, but we don't have any hardware to test. I don't feel like buying one from my own money though, i'd rather spend it on epdiy boards.
But in theory, it would just be adding a new board definition with the correct pins and it should work, if they didn't do any unexpected changes from the ESP32 version.

[martinberlin]

@ggros esp32s3 is already supported. As @vroland mentioned you need to add a board.
If no one wants to do the pull request I can do it, but someone has to test it because I also don't have a Lilygo S3.
https://github.com/martinberlin/epdiy-rotation/blob/lilygos3/src/epd_driver/board/epd_board_lilygo_s3_47.c -> That's when I tested it.
I cannot make a PR from there thought since I started from an outdated master. Just tell me if you are interested to try it once is implemented.

[ggros]

Yes interested to test, if I get it to work I will do the PR.

[martinberlin]

Hello @vroland
Since last update now there is branch main (default) and master (Seems older)
I recommend to delete old master because it bring confusion to those that have old forks and want to collaborate adding new features.

Update about adding Lilygo board S3:
It's not as easy as I though initially at least not without the hardware. Because the best way should be to copy a v2 board (It uses the same way to handle slow signals) but actually with the modern LCD mode, so it's not an easy take in my humble opinion.

[martinberlin]

Emailed Lilygo to see if I can get a discount coupon for Tindie. Sorry but I’m also refusing to buy a new S3 EPD047 since I don’t have any project with it and I’m doing it just to have it working with this epdiy update.

UPDATE: Lilygo is sending me an EPD047 S3 to my new address so I will hopefully collaborate adding a new driver. If someone wants an older but still 100% working Lilygo EPD047 ESP32-WRover version I can ship it just for the sending costs

[martinberlin]

The board arrived some days ago. After this end of the year time I will start slowly adding the new S3 Lilygo board. I will need some of you to test it once I make the pull request

[Fabian-Schmidt]

I also have an LilyGo T5 4.7 S3. Mine has as EPaper an ET047TC01-SD. The LilyGo T5 4.7 has an ED047TC1. Not sure what the difference is between them.

[ggros]

@martinberlin was busy lately to experiment more but happy to test your pr

[martinberlin]

The LilyGo T5 4.7 has an ED047TC1. Not sure what the difference is between them.

All that I know is that in S3 has a flexible display. Old one was not flex (And for me was a bit nicer)

[Fabian-Schmidt]

The LilyGo T5 4.7 has an ED047TC1. Not sure what the difference is between them.

All that I know is that in S3 has a flexible display. Old one was not flex (And for me was a bit nicer)

I found in a display database that the S3 display has supposedly a bit higher contrast.
Given that it is a different display also mean it requires a different waveform to operate properly?

[martinberlin]

Given that it is a different display also mean it requires a different waveform to operate properly?

You should ask Lilygo. All I know is that there is an open source one, and another Waveform: epdiy_ED047TC2 that they provided. Just try it out

[martinberlin]

By the way @THSLP13 are you still interested to have this working?
I started following what I did before in https://github.com/martinberlin/epdiy-rotation/tree/lilygos3 but I must say that even having the hardware I'm not motivated to do it. Managed to add the board without any problem but still bothers me LEH signal (Latch enable) is connected to the IO expander (This was not like this AFAIK since v4 of the PCB)
So the signal that is generated by hsync in the LCD module cannot be directly routed to a GPIO, as far as I know in my limited knowledge of epdiy, means that you still need to generate the LEH signal using another means. All this put me a bit down since that means this is not simply a board that can be copied from v7, it is in fact a mix between v2/v7 (RMT)

[martinberlin]

Update: Started with this https://github.com/vroland/epdiy/tree/203/lilygo-s3

However as I mentioned before, this is using LEH & STV signal via an IO expander, something that is not done AFAIK since v4 that already used an ESP32 GPIO for Latch enable. So I need to take a decision: I either implement Lilygo Solution, that is using a mix of LCD module and RTC to do this. Or someone else implements it and I send the Hardware to him/her, but ONLY if there is a commitment to implement it. Otherwise makes no sense.

I'm really very close to give up on this one, since I've more interesting things to do than fight with this piece of hardware.

[martinberlin]

Sorry guys but me at least, won't take any more time to work adding this board, for the facts mentioned above. After all, I do not have any interest at all, to use Lilygo S3 EPD047 board. Is really a nice thing that they got working the S3 in LCD mode, but as they've kept on using a v2 version of this project is really a weird combination.
Those who really need to use this "as is" but implemented in a newer epdiy version please use:
https://github.com/martinberlin/epdiy-rotation/tree/lilygos3

[martinberlin]

This is my video explanation of why I downvote this board to be added in epdiy:
https://youtu.be/r4-dz_x7K4k?si=h_v-dw4gx_59GZtV

@vroland if you agree then we can close this

[ggros]

@martinberlin in your fork I do not see recent commits, is it ok?

Where you able to make that board work along with CalEPD ?

[martinberlin]

Hi @ggros like I commented above it was decided that this board will not be supported in epdiy. So you can use either use my fork or Lilygo’s own repository.

Those who really need to use this "as is" but implemented in a newer epdiy version please use:
https://github.com/martinberlin/epdiy-rotation/tree/lilygos3

@martinberlin in your fork I do not see recent commits, is it ok?

Yes is an older version but for this board is the same. I'm really not willing to add this board for the reasons already described in this ticket. If someone wants to add it, this is open source, so just fork it and follow what I did. IMHO does not make sense to refactor many parts of the code just for this board, that is like version 2 of the PCB but with LCD component (Albeit in a much slower fashion than v7)

CalEPD is mostly for SPI and when I tried parallel it used epdiy as a component.