G6EJD / ESP32-e-Paper-Weather-Display

An ESP32 and 2.9", 4.2" or 7.5" ePaper Display reads Weather Underground data via their API and then displays the weather
Other
946 stars 206 forks source link

[SOLVED] 3 colors display and memory issue #179

Closed Giangi72 closed 2 years ago

Giangi72 commented 2 years ago

Hi, first of all, many thanks for sharing your code. This is a really fantastic project.

I'm having an HUGE issue on a 3 colors screen. I have a waveshare 7.5" 800x480 Black/White/Red display (https://www.waveshare.com/7.5inch-e-paper-hat-b.htm) and a Lolin D32 board (exactly the same in your schematic.jpg file).

I changed the row GxEPD2_BW<GxEPD2_750_T7, GxEPD2_750_T7::HEIGHT> display(GxEPD2_750_T7(/*CS=*/ EPD_CS, /*DC=*/ EPD_DC, /*RST=*/ EPD_RST, /*BUSY=*/ EPD_BUSY)); // B/W display in GxEPD2_3C<GxEPD2_750c_Z08, GxEPD2_750c_Z08::HEIGHT> display(GxEPD2_750c_Z08(/*CS=*/ EPD_CS, /*DC=*/ EPD_DC, /*RST=*/ EPD_RST, /*BUSY=*/ EPD_BUSY)); // 3-colour displays to reflect my 3-colors display

I tried do upload your code bu i got the following error c:/users/luca/appdata/local/arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: C:\Users\Luca\AppData\Local\Temp\arduino-sketch-F72BAE527F307002908925100E1A9BC0/Calendar.ino.elf section.dram0.bss' will not fit in region dram0_0_seg' c:/users/luca/appdata/local/arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: DRAM segment data does not fit. c:/users/luca/appdata/local/arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: DRAM segment data does not fit. c:/users/luca/appdata/local/arduino15/packages/esp32/tools/xtensa-esp32-elf-gcc/gcc8_4_0-esp-2021r2/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld.exe: regiondram0_0_seg' overflowed by 14256 bytes collect2.exe: error: ld returned 1 exit status Compilation error: exit status 1}` Initially the number was higher so I tried to save memory but I was fighting with bytes but the problem was on Kbytes. Do you know how to solve?

I also tried to leave the B/W display initialization, it was correctly uploaded but nothing was shown on display. Thanks

G6EJD commented 2 years ago

Your problem is the amount of memory needed to hold and display the 3-colour image, it needs 800x480x3 bytes that’s 144KBytes and far too much for the ESP32 to handle.

you can try the repetitive screen update in the GxEPD library so replace display.display with:

do { Displayweather(); } while (display.nextPage());

Really the 3-colour display is too big for the ESP32 to handle, BW no problem.

Giangi72 commented 2 years ago

Firstly many thanks for your answer. What I don't understand is that the board should have 512KB ram and 4 MB flash I thought 512KB for memory and 4MB for programs. After you wrote me I noticed, after a correct compilation: Sketch uses 818981 bytes (62%) of program storage space. Maximum is 1310720 bytes. Global variables use 74828 bytes (22%) of dynamic memory, leaving 252852 bytes for local variables. Maximum is 327680 bytes. So about 327 KB for memory and 1.3 MB for program, very far from 512KB and 4 MB. Additionally for 3 color display 8004803=1125 KB but you wrote me 144 KB. How do you calculated it? Considering B&W display 8004802 = 750KB I'm totally confused, what is the memory I have to consider to fit in for a display? The 327 KB or 1.3 MB?

I also tried you code but I got the previous error I also tried to modify the display definition with GxEPD2_750c_Z08::HEIGHT/3, I found it on internet: the code is correctly compiled but I got no response from board and display (tried many uploads and resets)

Do you know if there are any Esp32 board able to manage the 3 color display? Maybe D32 Pro? Because I'm confused about memory of my board I don't know what to look for in a new board. Many thanks

p.s. I know my questions are generic and not all of them are related to your project but I don't know where to post them. Do you know a forum where I could post them? :-) Another question sorry

G6EJD commented 2 years ago

GxEPD2_3C<GxEPD2_750c_Z08, GxEPD2_750c_Z08::HEIGHT> display(GxEPD2_750c_Z08(/CS=5/ SS, /DC=/ 17, /RST=/ 16, /BUSY=/ 4)); // GDEW075Z08 800x480

G6EJD commented 2 years ago

800x480x3 but each line is comprised of 1-byte per 8 pixels so 800/8x480linesx3-colour

you have to divide height by 2 not 3

mare you sure the display is connected correctly? That wires have continuity? Common problem

The 3-colour display will be very slow to update and takes a lot of power, battery life will be very short

Giangi72 commented 2 years ago

Ok, I created a simple project with do { draw(); } while (display.nextPage()); And in draw there are some strings, lines, circles. If I put the original GxEPD2_3C<GxEPD2_750c_Z08, GxEPD2_750c_Z08::HEIGHT> display(GxEPD2_750c_Z08(/*CS=*/ EPD_CS, /*DC=*/ EPD_DC, /*RST=*/ EPD_RST, /*BUSY=*/ EPD_BUSY)); everything works correctly If I write HEIGHT/2 The screen flashes and writes the first upper half screen and then flashes again and writes the second half screen in the bottom half and upper half = the same part up and down

G6EJD commented 2 years ago

The problem is also the huge JSON weather file that has to be downloaded and decoded, that takes a large chunk of the memory, but all this happens at run time so the compiler’s static analysis of memory requirement bears little resemblance to the actual requirement.

Giangi72 commented 2 years ago

I did some tests, here my results. Keep in mind that

program storage space = maximum is 1310720 bytes. AND 
dynamic memory = maximum is 327680

A simple drawing sketch, the same as before some strings, lines, circles.

305629 bytes (23%) of program storage space 
66068 bytes (20%) of dynamic memory

My old ESP32 sketch with WiFi and reading from my REST API and returning a JSON file

841045 bytes (64%) of program storage space
38056 bytes (11%) of dynamic memory

Then I merged them, not a real application but a sketch that read from REST API and perform some simple drawing (at the moment not linked together, just to put almost all needed code together)

910133 bytes (69%) of program storage space
87632 bytes (26%) of dynamic memory

This afternoon I'll do another test also merging all your drawing code but without the forecast data retrieving because I had a crazy idea: if the memory problem regards the retrieved data, I can create a new REST API that retrieve all needed data from openweathermap and only respond with smaller, not redundant, essential forecast data.

This only if putting the drawing code and increasing the JSON document size doesn't create a new memory problem.

Giangi72 commented 2 years ago

Additionally, I just discovered it is possible to see the old closed issues (the link was light grey)

I read again your suggest to write HEIGHT / 2 and replace

        DisplayWeather();
        display.display(false); // Full screen update mode

with

        display.firstPage();
        do {
          DisplayWeather();
        } while (display.nextPage());

But as I wrote The screen flashes and writes the first upper half screen and then flashes again and writes the second half screen in the bottom half and upper half = the same part up and down

Do you now what I'm doing wrong? Thanks

G6EJD commented 2 years ago

Have you tried removing /2 from HEIGHT / 2 so that it’s a full height buffer? It will update the screen in two parts, the top and bottom this is how it reduces the screen buffer memory requirement. your problem is still insufficient run-time memory regardless of what the compiler static messages are saying. Using the BW display was optimal for the code and the colour display is not, it’s not an easy problem to solve as your exceeding the capacity of the ESP32

Giangi72 commented 2 years ago

Hi, I created a new sketch with your drawing methods, my REST API (4096 Bytes JSON response) and simple drawings

914685 bytes (69%) of program storage space
87672 bytes (26%) of dynamic memory

same as before just increasing to 10240 then 204800 Bytes the JSON response

914689 / 914693 bytes (69%) of program storage space 
87672 bytes (26%) of dynamic memory

I don't understand why dramatically increasing the JSON file almost nothing changed but it is ok for me.

Giangi72 commented 2 years ago

ATTTENTION: my fault

everything works correctly using the pageloop and half buffer without modifying your code.

I did 2 silly errors in my tests: 1) in the simple draw test I wrongly put display.display(false); in the drawing method and the page loop simply went crazy :-( 2) in your code I forgot the half buffer

So, SUMMARIZING, forget ALL my previous messages.

If anyone has the 3 colors display can use G6EJD's code simply adding the half buffer

GxEPD2_3C<GxEPD2_750c_Z08, GxEPD2_750c_Z08::HEIGHT/2> display(GxEPD2_750c_Z08(/*CS=*/ EPD_CS, /*DC=*/ EPD_DC, /*RST=*/ EPD_RST, /*BUSY=*/ EPD_BUSY));

then replacing

        DisplayWeather();
        display.display(false); // Full screen update mode

with

        display.firstPage();
        do {
          DisplayWeather();
        } while (display.nextPage());

as G6EJD correctly suggested

Thank you very much for your help and your patience

p.s. I wrote [SOLVED] in the title hoping this can help other people