1.8" lcd tft ST7735S display is changing the image slowly - Page 1
Forum section: electronics / general

author: stoyanoff
author_rank: Contributor
timestamp: July 27, 2021, 06:22:45 pm
content: Greetings! I have my own program base on the arduino example, but modified for TI MCU. I am using SPI interface to control the display, but in comparison to the youtube videos, my tft updates quite slowly. For example it takes around 1 second to change the entire screen color. There are no delays in my code and everything depends on the spi baud rate. What baud rate do you use? In the videos I`ve watched the lcd image changes immediately. It is visible how my lcd changes pixel by pixel row by row the entire image. Could you give me a little bit more info so i can make a comparison?Thanks!

author: SiliconWizard
author_rank: Super Contributor
timestamp: July 27, 2021, 06:34:58 pm
content: SPI rates with this controller can be up to 10-20 MHz. What are you using?Also, from what I remember (another thread), the Arduino libraries may send bytes one by one instead of by blocks, which would slow down things dramatically.

author: DavidAlfa
author_rank: Super Contributor
timestamp: July 27, 2021, 08:26:50 pm
content: Explain better. Better to post some of your code related to the display writing and the spi settings.Looks like it's doing an extremely uneffective transmission, or even bit-banging.

author: ajb
author_rank: Super Contributor
timestamp: July 28, 2021, 02:43:00 pm
content: Which TI MCU?SPI at 15MHz (what that controller looks to be specified for) should be able to update a 128x160 display in 21ms if you're using 16 bit color. So first thing to check would be that you have SPI running at a reasonable speed, and hopefully you are using an SPI peripheral and not bitbanging it like a lot of LCD sample code shows.Is the MCU doing anything else other than controlling the LCD right now? If so, it's possible that the MCU is spending too much time on other things to be able to service the LCD properly, and it's a good idea to take out everything but the LCD stuff as a first troubleshooting step.Once you've covered those things, there may be other things you can do to improve performance, like use 16 bit instead of 8 bit transfers as SiliconWizard suggests, and ensuring that you're loading new data into the SPI data register as soon as you can (usually there is a 'data register empty' flag that says the data register is ready to accept new data, and a 'transmit complete' flag that says the previous data has finished sending. You want to load the next byte or word when DRE is set, since that happens before TXC, and will give you basically continuous transmission). But none of these will make as much difference as making sure your SPI interface is performing properly.

author: stoyanoff
author_rank: Contributor
timestamp: July 29, 2021, 12:10:05 pm
content: I don`t have any other tasks applied to the MCU, but it seems too much time between the bytes the issue. My LCD`s DC, RST and CS are connected through 74HC373 octal buffer. So it seems my control function is quite inefficient. I`ll make some changes and I think everything would be fine.Thanks!

author: Buriedcode
author_rank: Super Contributor
timestamp: July 29, 2021, 11:16:23 pm
content: How does this compare to say and Arduino UNO?I noticed many of the LCD/TFT/GFX example libraries aren't particularly efficienct, sometimes addressing and setting up each individual pixel to fill a screen, which can end up being 8-10 SPI writes per pixel, instead of the usual 1 for 8-bit colour or 2 for 12/16 bit.You could always add a simple counter that increments every time the SPI sends a byte, then display this on the screen after its finished writing a whole screen.