TFT library speed

[Dean_b_white]

Hi, I wrote a graphics library for a Nokia5110 some time ago and it worked fine but have recently decided to step up to a TFT with 16 or 24 bit graphics. I've decided I don't want to create a tonne of code bases for all the combinations so split the library so the graphics part is entirely device independent.

The 1 bit LCD output using hardware SPI is very fast and refreshing the entire screen via a buffer works well. However I'm not too sure how this approach will go with a 320*240 or higher TFT.

I'm looking at getting one connected with either 8 or 16 bit parallel as a lot I've seen on youtube with SPI seem really slow.

I rewrote a LED matrix library and made it use the graphics library and it seems the real bottleneck is sending the data and thus a huge improvement was made when just sending the bytes that had changed between refreshes. On the UNO I got the refresh from sluggish and unbearable to 100+ frames a second. Most of the improvement came because the original library was sending data to the LED array for every pixel.

I have a library that works well at the moment with 1 bit devices but wondering if I will need a different approach for higher pixel bit depths.

I have an Arduino Due at the moment and it will be able to hold the buffer in memory. I've been trying to think of a way to seamlessly mark areas of the screen as "updated" and when a refresh is done only send these regions. Was thinking about splitting screen into 8*8 regions and using 1 bit to store if each had been written to since the last refresh.

I guess this approach is memory hungry but is basically double buffering and should avoid flashing that occurs when erasing with background colors and redrawing new objects.

[Andy Brown]

Hi Dean,

If you've got enough memory for a full frame buffer and you have enough speed to beat the refresh cycle (about 1/60s) then the ideal method is to synchronize your upload with the TE signal and just refresh the entire display. My FPGA graphics accelerator refreshes the display like that.

The truth is that MCUs are not FPGAs and don't often have the raw grunt to do a full refresh at the required speed so your method of keeping a 'dirty' map seems worth trying. You'll solve the worst flashing visual effect but will still get 'tearing' because you won't be fast enough to avoid the refresh cycle.

I'm not familiar with the Due but if it has an external parallel interface then you might be able to make it fast enough. SPI will be a non-starter. Way, way too slow.

Regards,
- Andy