ICN2053 and Raspi or ESP?? ::: 64x1280 to run gif

[dpunzeng]

Hi Sebi, whow - your code is the first to work on my new, beautiful stack of 64x128 bloody 2053 panels I already have. It took me three nights to get here!! Now light is on and your demo runs. I am a bit overwhelmed with your code - dispite the fact it does not fill a telephone book :) I manage to compile 64x220 over on and ~1/2 panels but then it hits a wall. I want to build a fairly static (probably gif) display that changes every now and than - no video display with 64 x 1280.

Can I interest you in helping me to do the next step? Not sure if it is:

• extending your code to run 1280 wide
• lifting it into hzellers library
• driving every panel individually with esp32
• ... rgds diet

[SebiTimeWaster]

Hi, as long as you don't want a certain fps rate there is no theoretical limit to the amount of panels in one row, it will just take longer to latch out the data. I'm a bit confused by the "64x220" value, because the amount of pixels can only be dividable by 16. So what happens when you try to specify a 1280 wide screen? I presume its an out of memory compile error? My library is written to reach the highest possible speed on cost of memory usage, so there is a maximum of image data an ESP32 can hold. There is a thread in hzellers github page about the topic of porting the code to run on Raspberry PIs, could be interesting for you. So far i think only proof of concept work was done. If you want to stay on ESP32s just do multiple ones in parallel and connect to a server with wifi, should work fine.

[dpunzeng]

Hi, thx for reply. Up to 64x220 I can download and it displays (see pix attached). Over 220 I can compile and download, but no light and wired hex jumble running permanently in the console – I guess unrelated, because there is no println or so. I checked your loops and parameters (understood only 5% - I guess) but I can not see any limitation in the loops or so. Greetings from winter wonderland Vienna, diet 😊

[SebiTimeWaster]

hi, your reply just contained the complete email header including your name and email adress, i deleted that for you. maybe answering on a computer instead of per email is a good idea.

"but no light and wired hex jumble running permanently in the console" This is an outcome of the program code being overwritten by image data, means the size you specify is too big for the available dynamic memory. so i was wrong about there being a compiler error, it is a runtime error.

this is from the documentation: "The internal buffer is written to in the same format as the data would be sent to the panel, which makes the buffer 16 times bigger than needed, but as a trade-off one gets 7 FPS more out of the ESP32 since the formatting of the data is strictly held in the image generation task, not the refresh task."

you now have these options:

• rewrite the library to move the image data generation to the core that runs the refreshing to gain 16 times more free memory on the cost of FPS
• wait for a usable library for Raspberry PIs
• use more ESP32s

[dpunzeng]

…did not read carefully to the end of your mail.

Below the successful compile and upload log. To me it seems, there is plenty of ram. And 220 is just a notch more than 128. Could it be my board? Currently it’s a ESP32DevkitV1 with 520K SRAM (DOIT Esp32 DevKit v1 - Zerynth Documentationhttps://docs.zerynth.com/latest/reference/boards/doit_esp32/docs/) I found in the useful-box.

Re porting to hzeller: Well: in your code is the magic init string from the Russian guy. In hzellers framebuffer I found the place where fm2126 is initiated. Guess this could serve as a template. Problem is, its fare over my head – that’s my feeling. Intellectually I see the picture, but on the keyboard – shaky shaky

Raspi would be known ground and would fit snug to the rest of the project. ESP would also be ok, if raspi is out of reach. Reading your reply, it should work. Do you think I could drum in my payload via rs232. Pins would still be free. Wifi does not fit nicely, I would like to hand over the gifs from the raspberry as the “master” controller.

Cheers Diet

Sketch uses 215705 bytes (16%) of program storage space. Maximum is 1310720 bytes. Global variables use 16284 bytes (4%) of dynamic memory, leaving 311396 bytes for local variables. Maximum is 327680 bytes. esptool.py v2.6 Serial port COM3 Connecting........__ Chip is ESP32D0WDQ6 (revision 1) Features: WiFi, BT, Dual Core, Coding Scheme None MAC: 30:ae:a4:39:48:20 Uploading stub... Running stub... Stub running... Changing baud rate to 921600 Changed. Configuring flash size... Auto-detected Flash size: 4MB Compressed 8192 bytes to 47... Wrote 8192 bytes (47 compressed) at 0x0000e000 in 0.1 seconds (effective 1092.3 kbit/s)... Hash of data verified. Compressed 15856 bytes to 10276... Wrote 15856 bytes (10276 compressed) at 0x00001000 in 0.2 seconds (effective 700.8 kbit/s)... Hash of data verified. Compressed 215824 bytes to 111202... Wrote 215824 bytes (111202 compressed) at 0x00010000 in 2.0 seconds (effective 877.8 kbit/s)... Hash of data verified. Compressed 3072 bytes to 128... Wrote 3072 bytes (128 compressed) at 0x00008000 in 0.1 seconds (effective 402.9 kbit/s)... Hash of data verified.

Leaving... Hard resetting via RTS pin...

[SebiTimeWaster]

image data: 64 x 256 x 16 = 262 kByte. plus other program data: unknown, didnt measure it ESP32 memory: 520 kByte. result: out of memory.

the size of a variable is also limited by the amount of memory that can be allocated in one continuous area.

i suggest you go to the hzeller thread and ask there what the progress of a Raspberry library is.

[dpunzeng]

thx - unfortunately its very quiet over there in the raspi corner. Question: In your code, its demo images. Is there any other code you know, that runs a gif on 64x128 on 2053? I could split the gifs on the raspi and distribute it on several esp32. Would you be interested in helping me or do you know someone who might be? Thx Dieter

[SebiTimeWaster]

unfortunately i am not interested in changing the library, it comes as-is.

but it should not be hard, just replace lines 186 to 248 with something like this:

for (unsigned int x = 0; x < DISPLAY_WIDTH; x++) {
    for (unsigned int y = 0; y < DISPLAY_HEIGHT; y++) {
        // fetch the pixel values from your own data here:
        unsigned char rByte = ???;
        unsigned char gByte = ???;
        unsigned char bByte = ???;

        // write the data into the cache
        cacheWrite(inactiveBuffer, x, y, rByte, gByte, bByte);
    }
}

[dpunzeng]

ok, great, thx for your input. I give this a try...