0
\$\begingroup\$

I have a 1.8" TFT color display from Banggood. It's very nice with the vivid colors.

However, the screen refresh is slow. I'm limited by the SPI speed of 1 MHz. It results in an update rate of:

160 pixels x 128 pixels x 16 bit/pixel ÷ 1 MHz = 0.33s per frame

Effectively, it's even lower as the Teensy LC stops for about 1 cycle after each byte and there is overhead between the SPI transactions. So it's more like 0.5s per frame or 2 fps, which is very noticeable. It's more like a left to right swipe animation (see image below).

1.8" TFT display with breadboard

So my question is:

  • Is the speed limited by the display controller chip, probably a ST7735?
  • Or is the speed limited by my breadboard wiring?
  • Is there a faster display available where I could use the SPI bus at 4 or 8 MHz?

Update

Here's a picture of the bottom of the board.

enter image description here

Not much to see:

  • The SD card slot and the three resistors R1 to R3 are not used.
  • The resistor R4 close to the LED pin (right most on the image) is connected to the LED pin and has 7.5Ω (7R5).
  • The part with three legs in the top corner reads "V2PK". I guess it's a voltage regulator that would be used for 5V operation. I operate it a 3.3V. There's also a capacitor and an open jumper close to it.

The interesting part is probably hidden between the PCB and the display.

\$\endgroup\$
7
  • \$\begingroup\$ A question here needs to be based on actual solid information - you need to specify the actual controller chip and check its data sheet. Your wiring should be good to well more than 1 MHz. You may also want to look into feeding the SPI via a DMA engine in the Teensy's Kinetis chip. And you also need to consider where the data is coming from - if you are pushing it over the USB, while in theory that could be fast, typical implementations you are likely to have used could be quite slow. But in the end, no, SPI isn't considered a high speed display interface. \$\endgroup\$
    – Chris Stratton
    Oct 8, 2017 at 19:58
  • \$\begingroup\$ I'm using the DMA to feed the SPI. And I've checked it on the scope. The Teensy can easily generate proper SPI with 2 MHz but the display stops working. Unfortunately, I don't know the exact display driver chip specification as Banggood didn't specify it and the chip is not visible on the board. However, I've based my implementation on the ST7735's datasheet and it seems to match. \$\endgroup\$
    – Codo
    Oct 8, 2017 at 20:10
  • \$\begingroup\$ @Codo could you please post the picture of the bottom of the display board? I need to see if there are series resistors... Alternatively: can you confirm that the board is exactly what you have posted? As a second question: did you try without DMA (but with a 4MHz spi?)? \$\endgroup\$
    – next-hack
    Oct 8, 2017 at 20:26
  • \$\begingroup\$ I've added an image and a description of the bottom side. I can't see any series resistors for MOSI and SCK. \$\endgroup\$
    – Codo
    Oct 8, 2017 at 21:08
  • 1
    \$\begingroup\$ After further analysis it seems to be a software problem rather than hardware problem. But I haven't found the root cause yet. The images are generated on a Mac and are sent via USB to the Teensy and then via SPI to the display. Even though the image is split into pieces of 2K, the transmission throttled to about 80% of the SPI speed, a robust memory management in place that drops data if insufficient, efficient processing in interrupt handlers and via DMA, an unpredictable hiccup seems to occur for speeds over 1MHz. The Teensy 8K RAM is rather small for this kind of setup... \$\endgroup\$
    – Codo
    Oct 9, 2017 at 16:05

3 Answers 3

Reset to default
1
\$\begingroup\$

TSCYCR, Serial clock cycle (Read) is 150 ns. That is 6.6 MHz. But don't expect miracles of a SPI display. (it might work just fine at 10Mhz)
The software should be optimized to update the least amount of pixels per refresh.

There are still a few things you can do:
- Reduce the color depth.
- Use a longer word. (eg: 16 instead of 8 bit)
- Make sure the SPI routine, if blocking, is as short as possible. Don't wait for the spi to complete, wait for spi to be ready for a new word.

If you want a fast display, get a parallel one with frame buffer you can do operations on.

\$\endgroup\$
6
  • \$\begingroup\$ Thanks for the reference to the TSCYCR. So the chip - if it is a ST7735 - should be capable of higher speeds. Now if I only knew which part doesn't work beyond 1 MHz. And as for the tips: Optimizing for minimal refreshes is certainly an option. Possibly reduction of color depths as well. Blocking is certainly not a problem as I'm using DMA. Longer words would only improve the speed by about 6%. \$\endgroup\$
    – Codo
    Oct 8, 2017 at 20:15
  • \$\begingroup\$ In fact, TSCYCW (instead of TSCYCR) is relevant as I'm writing data to the display. TSCYCW is 66ns, which is 15 MHz. Even stranger... \$\endgroup\$
    – Codo
    Oct 8, 2017 at 20:21
  • \$\begingroup\$ You should not look at TSCYCR, but TSCYCW, which is 66ns. This means 15 MHz. With 8 MHz you can "easily" go up to 20 fps on that display. \$\endgroup\$
    – next-hack
    Oct 8, 2017 at 20:24
  • \$\begingroup\$ @next-hack yes, that is right. Except changing SPI frequency on the fly might be a bit inconvenient. That's why I went with the slowest. \$\endgroup\$
    – Jeroen3
    Oct 9, 2017 at 6:12
  • 1
    \$\begingroup\$ It turned out to be a software problem. But your answer confirmed that I hadn't reached the limit of the display yet. So I kept working on it and found the solution. \$\endgroup\$
    – Codo
    Nov 23, 2017 at 20:31
1
\$\begingroup\$

I got the best result (over 30 fps) using the TFT_eSPI library https://github.com/Bodmer/TFT_eSPI where the content is buffered into a sprite. The baudrate set in the config file that worked flawlessly (on my board) was. This code was running on an ESP32 which was connected to the display.

#define SPI_FREQUENCY 40000000

\$\endgroup\$
0
\$\begingroup\$

It's now properly working. On a Teensy LC it runs at 16 MHz, on a Teensy 3.2 it runs at 18 MHz. Both are the maximum SPI clock rates for these boards.

It turned out to be a software problem. The main problem was that I hadn't properly disabled DMA. It would then kick in too early on the next SPI transmission, i.e. it would start with the first byte of the transmission even though it was supposed to start on the second byte. This mixed up a few thing and left the device waiting for the last byte to be transmitted.

I still do not really understand why it worked at lower frequencies but failed at higher ones.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.