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.
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.
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).
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.
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.
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
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.