Watching movies on 128x128 1.45" Full Color TFT LCD Display

[mleo]

The web page describing the 128x128 1.45" Full Color TFT LCD Display shows it running at 21 fps over SPI. What it doesn't show is what's driving it. What is the SPI frequency needed to do this?

Crystalfontz LCD Blog

Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.

 

[CF Tech]

That demo was made (long ago) using a prototype Cypress PSoC processor. I believe it used a uSD card and maybe DMA to make the transfers fast enough.

If it is 16bpp and 21 FPS:

128 * 128 * 16bpp = 262,144 bits per frame​

frame time = 1/21 seconds​

bit rate = 5.5Mbps (in a perfect world)​

In real life, you will need a higher clock rate since there are times when you cannot be transferring the data.

This video describes a similar project:

We also have a demo that uses an ESP32 to push a movie to the 240x240:

code here:

GitHub - crystalfontz/CFAF240240A1-013T_Video: Video playback on a 240x240 1.3" display from an SD card using the ESP32

Video playback on a 240x240 1.3" display from an SD card using the ESP32 - crystalfontz/CFAF240240A1-013T_Video

github.com

 

[mleo]

Thanks for the quick reply. The Arduino Mega has a max SPI 8Mhz clock I think. So it should ( barely ) do 21 fps. I'm not displaying a movie, but I'm trying to update about 1/4 the screen, a block 60x60 pixels. So 60 * 60 * 16bpp = 57600 bit/update. 8M/57600 = 138.8. I'm barely getting 5fps. I'll look into this. Maybe it's running software spi.

 

[CF Tech]

There can be so many places that can slow down a transfer. Do you have an oscilloscope to see what is going on?

 

[mleo]

I do. I'll try that today.

 

[CF Tech]

I find it useful to use a spare port as a trigger and an overall timer.

void function(void)
  {
  setdebugport(); //set scope to trigger on this
  . . .
  for( . . .)
    {
    //spi transfer, etc //look at these signals on other channels
    }
  . . .
  clrdebugport(); //measure (a close approximation of) overall function execution time to here
  }

You can trigger your scope on the setdebugport() and measure the overall time by looking at the pulse width. Your SPI transactions can be viewed on another channel and they will be "bracketed" by the debug pulse. I often end up moving those set and clr functions around -- bracketing the fiddly bits of code that I am trying to optimize -- that way you can tell where the code is spending its time.

At some point, you can get the pulse overhead by measuring this "empty" pulse width and (mentally) subtracting it from your other measurements.

  . . .
  setdebugport();
  clrdebugport();
  . . .

And you can see function overhead by comparing the first example (set / clr just inside the function) to this (set / clr just outside the function):

  . . .
  setdebugport();
  function();
  clrdebugport();
  . . .

If you have interrupts going that may make the debug pulse stretch and bounce on the scope as the processor wanders off to do other things. If that is making the debugging useless you can temporarily turn off interrupts just outside of the set / clr .

 

[mleo]

Thank you! This going to help. I'm working with test code now. Once I start working with the project code this will help.