Closed Giangi72 closed 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.
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
GxEPD2_3C<GxEPD2_750c_Z08, GxEPD2_750c_Z08::HEIGHT> display(GxEPD2_750c_Z08(/CS=5/ SS, /DC=/ 17, /RST=/ 16, /BUSY=/ 4)); // GDEW075Z08 800x480
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
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
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.
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.
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
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
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.
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
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
inGxEPD2_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 displayI 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 regiondram0_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: region
dram0_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