I am new to this and been trying to design UI using Squareline. The problem is almost all my designs result in a code that is too large for my ESP32 S3 board.
Obviously there is something wrong here. Even the template examples of Squareline is too large and I get the memory error.
Either I am not generating the code from the software efficiently or the board does not have enough RAM.
How do people upload big UIs in their board? Am I supposed to use the SD card that usually comes with the display boards?
A simple one page UI is taking 80% of my ESP32 S3 board using 16 bit color depth. Very confused!
The section after the last dash tells you the ram and the flash size. the N or H indicates flash size while the R is for RAM. the number is megabytes. if there is no listing for the RAM then the default amount of 512K is used. If you do not have the board set up properly and you do not write a partition file using esptool then you will probably only end up with 384K of storage.
Thanks for the reply.
My board is ESP32 S3 -N8-R2
So I should have around 3.3Mb of app memory with min SPIFFS and OTA.
My question is:
Is it reasonable that a one page UI of the “eBike” Squareline template is about 1.5 Mb? That seems too high to me for any of common boards like ESP32s.
I mean it is just one page, and what if a project has more pages as it is usually the case.
Am I missing something here or this is normal?
Also, is there anyway to increase the flash memory of the board to upload bigger UIs if needed? like using the SD card that usually comes with display boards?
Not if it’s stored as RGB. Even if you are running 16bit color it’s 3 bytes per pixel. 2 bytes for RGB and the last byte is for alpha. So if you are using a 480 x 320 display the amount of data the image alone is going to take up is going to be 480 * 320 * 3. That 460,800 bytes just for the single image. Now the e bike has 3 images of that size that it uses if I am not mistaken One for each of the gauges and the 3rd is the background. I would have to double check and see if the gauge images are the same size as the background image but I believe they are.
You are better off using the raw PNG data as it takes up a lot less space. There is more processing on the back end because the data needs to be decoded but that is only going to happen on startup. You have to make sure you also edit the LVGL config header file and turn the PNG decoder on. I don’t remember if it is on or off by default. The ESP32 is not going to have an issue with decoding the data.
what you do is make an array just like what you currently have but do not populate anything in the header section of the lv_img_dsc_t (I think this is the name) structure. Leave it empty no width or height or image format. just the data and that’s all. the rest of the information is embedded into the PNG data so the decoder is what fills in the blanks.
You have to remember that is an example and is supposed to have a “wow” factor to it. You have to get creative if you are going to have a lot going on and maybe take it down a couple of notches and render more things instead of using images. You do also have the ability to read data from an SD card as well if you really want to use images. again store them as PNG tho otherwise they will take up a large amount of space.
Here is an example of things you can do. This is written in Python so it is using MicroPython that has been compiled with LVGL built into it.
that entire script including the embedded image is 70k in size.
LVGL is not able to make radial gradients so I made a radial gradient using a paint program. I made it in black and white and then turned the black into alpha leaving only the white. I resized it to 250 x 250 to keep the amount of data used low but not too low where it would look like crap when I resized (zoomed) the image. That image is used for 3 parts of the widget. I resized it and rotated it for the 3 different pieces. That is where the “creative” part comes in. If there are elements that can be reused then you are going to want to do that. you have the ability to rotate and resize and there is a lot that can be done with doing that.
You can use images to spice up a lot of the built in widgets also. The arc widget for example, you can make a conical gradient in a paint program and shrink the size down and resize it and use it as the indicator for the arc.
I really appreciate you taking the time explaining this to me. Super helpful for a beginner like me.
I am going to try the tips you mentioned and will post the results here once I have it.
I am a beginner as well. Have only been using LVGL for 5-6 months. It’s a lot to learn I will say that. Storing static images that are the size of the screen is going to consume a lot of storage. But then on top of that it is going to consume a lot of RAM too. Even if you store an image in PNG format it will expand out to almost 500k of ram when loaded. So be careful of that also. 8mb seems like a lot until you load half a dozen images and end up getting low on memory.
Exported code size is result of assets. Bigger display bigger assets bigger fonts usw.
For example 6 screens app 240x240 disp some fonts exported around 800kB
You is boss for your project…
For example TouchGFX latest added support for SVG vector images, then image in flash have 3kB instead bitmat 187kB …
One of the things I did want to mention to you is lowering the bit depth down to 16 and dithering the image. You will not notice the change on a small display. If anything it may actually look better.
A project I am working on now I needed a full screen background for a 480x320 display. Using a PNG file set to 32 bit color the single PNG took up 193K of storage. The display is only able to do 16 bit color and I didn’t need to have an alpha channel.
The image on the right is the one that has the lower color depth. When I tell you how low it is you will be amazed. It’s actually 8bit color. That image is not zoomed in or out at all. it is the native size. When I zoom into the image and make it 200% then you can see the artifacts caused by the low bit depth.
Had I tinkered about with this before I resized the image the results would have been better. if you have a large resolution image and drop the bit depth and dither it before resizing the image smaller the results might be better it depends on the program you are using to edit the image. some programs you have to watch out for because they do not edit in the bit depth the image is saved in. so any changes made will be at 32 bits until you save it and reopen the image. Don’t know why they are like that but they are. They won’t even reload the image after saving it, you have to close and reopen the new save file to see the results.
