My problem is that is if I define 6 displays, I run in to ram problems the device does not have PSRAM so this is not an option… So I discussed this problem with the owner and he suggested to update the displays 1 by 1 by cycling through the CS pins. Like this:
For some reason if I execute the update_bar1_script the display stays black. I asumed the we have a timing issue, so I am trying to use the set_cs_pin() method form the ili9xxx display component something like this below:
I am not an C++ expert, but by searching the web, this is where I landed ;). It is giving me a hard time…
That won’t help as each display instance will still allocate a screen-sized buffer, and doesn’t release it just because the CS pin is disabled.
What is the resolution of the small displays? You can use LVGL to drive multiple displays, each instance can work with a buffer as small as 1/4 the screen size. That might work.
@clydebarrow thank you for sharing your insight!
The idea is to release the CS pin when the data is writen. (display.update)
The following cycle is what I have in mind:
on boot write all cs pins high
write cs pin from display 1 low
draw the display 1 with a script (lines/text/icons)
display_id.update()
write cs pin from display 1 high
write cs pin from display 2 low
draw the display 2 with a script (lines/text/icons)
display_id.update()
write cs pin from display 2 high
etc.
The thing is if i create 1+6 separate instances it will crash on ram shortage. (software resets when i execute a display.update()) I am not sure how LVGL can help me with this…
Oh, gotcha now - one display instance, 6 CS pins separately controlled. Best way would be to not specify the CS pin in the display config, and use update_interval: never. The from a script turn on one CS pin, set a global variable to identify the display to update, then call the display update method.
However, you are still going to have to do something clever to get the init sequence sent to all displays. That’s going to be harder. Oh maybe send it to all displays simultaneously.
Using LVGL instead would mean 6 ili9xxx instances, but no display lambdas, and a 25% buffer in LVGL. That would mean for 6 displays you only need 1.5 times the display buffer size (the display component does not allocate a buffer in this case.)
The main display could also use a small buffer, so overall RAM usage will be down. And you would not have to jump through hoops to control the displays.
Now I need to figure out if I need if i need to do this every update or will a on_boot do the trick.
Thanks for the kick in the right direction! I will do some more testing and will also give the LVGL library a try it also takes care of some other things (like paging).