Big Tree Tech Panda Touch

[bensuffolk]

I add a comment to the previous discussion #825 , but then realised it was closed, so was not showing up here for discussion. Probably better to get the original discussion re opened again, then all the history is on one place.

Here were my observations : #825 (comment)

I have acquired one of these Panda Touch devices. Flashed it with the default firmware and see some odd behaviour:

Most of the time on power on the screen simple rotates through sold colours, White -> Red -> Green -> Blue -> Black then repeats back to white. Whilst its doing this its connected to MQTT and responding to touch sending then correct commands etc when you press on the relevant screen area. So its a display issue of some sort. Maybe its not been correctly initialised (I'm not sure if this solid colour behaviour is a default of the screen hardware?).

You can issue a reboot command via MQTT or the web interface and then its boots up correctly and the display functions with the correct content as expected.

There is a constant high frequency flicker on the screen, maybe linked to refresh timings, if all objects are hidden this is still visible on the background colour so I don't think its related to the number of objects. In fact thinking about it, it's visible on the boot logo screen, which presumably happens before any GUI objects are created.

I didn't notice this flicker on the solid colours error it has on power up before the reboot.

Changing the backlight brightness does not seem to make any difference to the visible flicker.

[bensuffolk]

So the first part is an easy fix, extending the delay after the reset allows enough time for the reset to occur before sending commands. I have added a pull request #984 with that change.

[bensuffolk]

I have checked the example code from BTT which has various buffering options, the main ones seem to allocate 1 or (2 for double buffering) frame buffers the size of the screen (800 x 480) from PSRAM.

I checked the PSRAM usage on the status web page and can see most of the 8MB is free, so am I right in thinking that the graphics code is still working on the basis of the original very low memory devices and does not really use the PSRAM if its available for graphics buffering?

[fvanroie]

RGB panels always require a full frame buffer in PSram and won't work without it. This is normally done in the graphics driver (Lovyan or ArduinoGFX) automatically. I don't recall ever implementing double buffering... You should see at least 768kB being using from PSram.

LVGL draws it's UI in chunks and copies that to the framebuffer, maybe that's where the confusion comes from.

[bensuffolk]

I have never really looked at graphics stuff, generally stick to back end work. I will see if I can figure out the flickering, but I have also just flashing a waveshare 4.3 device I had laying around from another project, and it does the same. So I guess it's a generic issue with larger resolution screens.