Go Down

Topic: Refressing speed of KMR-1.8 SPI TFT  (Read 359 times) previous topic - next topic

MPM2017

KMR-1.8 SPI TFT is 128x160 pixels display having ST7735 (propably version R) display driver.
I wrote an installation code based on the datasheet of ST7735 and various exmple code available
on net (typically for Arduino). I managed to make the display operating. The only (and major)
problem is that refressing the hole screen takes 6-7 seconds. This is not caused by the
SPI (which drives at speed 0.4-1 Mbit/s) but its about the display driver itself. I have a normal
initialization for the ST7735 which sets the refressing rate around 60 Hz which should be well
fast enough for my application. I wonder what is the reason for the slow refressing. Could it be
some kind of energy saving mode accidentaly selected ? Any ideas or experience of other users ?
Propose me any idea what could be the problem. I have tested two display units and they behave
similarily.

david_prentice

#1
May 12, 2017, 05:32 pm Last Edit: May 12, 2017, 06:00 pm by david_prentice
My library takes 48ms to fill my ST7735S 128x160 screen running on a 16MHz ATmega328P.

If your library is taking 6000ms you must have a problem somewhere.

If there is a 60Hz refresh rate,  I should see the screen take about 3 refreshes to complete the new colour in the GRAM memory.   e.g. a video or photo will catch partial views of the screen changing colour about 53 pixel rows at a time.

Your slower performance will be hardly noticeable between frames.  360 refreshes have occurred during your fillScreen()

David.

MPM2017

I'm not using the library which is available for Arduino. I had to write the functions for another platform. I just wonder should I have set the TFT to some condition while writing to the image memory like switching it of while writing the data. I noticed that in case I execute a reset for the TFT and after it returns to normal display mode the TFT shows immidiately the current image from its memory (normal refressing speed).

david_prentice

Go on.   If you have written your own functions,   I would guess that you read the data sheet first.   Any TFT datasheet !!!

The theoretical time to write 160x128 pixels with an 8MHz SPI bus is 40.96ms
I manage 48ms.  You manage 6000ms i.e. you are 146x slower than theoretical.

David.

MPM2017

Go on.   If you have written your own functions,   I would guess that you read the data sheet first.   Any TFT datasheet !!!

The theoretical time to write 160x128 pixels with an 8MHz SPI bus is 40.96ms
I manage 48ms.  You manage 6000ms i.e. you are 146x slower than theoretical.

David.
Thank you for your help.

I think I found the reason for my problem. There was some extra delays in my SPI-routine. I had added few microseconds delays which actually were not necessary and caused really much delay. Then I have an additional problem with one TFT. Its back light is not uniform. By pressing the foil connector the light intensity either increases or decreases. I think that just a bit bad soldering. Luckily just one of my TFTs shows this problem. I declare this problem solved.

Mika

david_prentice

Ah-ha.   If you have 40960 SPI bytes,  you only need a 150us "delay" per byte to get a 6 sec screen fill.

I had assumed you were doing 20480 separate drawPixel() calls.   That would also be slow.   i.e. theoretical 143ms.

David.

Go Up