I'm using an 160x128 LCD based on the ST7735 connected using hardware SPI to a Nano 33 BLE.
And I find all screen operations too slow...
As an example, a fillScreen() takes about 1second !
I'm using the Adafruit GFX and ST7735 libraries downloaded from the IDE library manager.
What can I try ?
Hi,
Actually 1sec to fill 160x128 sounds about right. Please think about on a fill() every Pixel must be Set a certain 1 or 2 Byte value depending on 256 or 65536 color TFT.
Now I have to ask: what are you trying to do? If you want to write dynamic values, best you can Do is rewrite the old value in background color and then write New value in Text color. An example for that you can find in my project:
Check out removeText and addText methods
Are you writing the display buffer every time you modify a pixel?
What can I try ?
Try posting the code, using code tags.
I find it slow in different ways. When clearing the full screen or displaying a bitmap:
tft.fillScreen(Display_Background_Color);
tft.drawBitmap(0, 33, ssLogo, 160, 62, Display_Text_Color);
But also when printing text / numbers, where I am careful to beforehand print the old text before, in the background color, thus only rewriting the minimum necessary. Even by only overwriting the changed digits, the new ones can be seen being redrawn.
void prtDigit(char digit, byte x, byte y, uint16_t color) {
tft.setTextColor(color);
tft.setCursor(x, y);
tft.print(digit);
}
// assumes oldSpeed, newSpeed are positive
void prtSpeed(uint16_t text_color) {
// splits speed into 4 digits and compares them
// assumes decimal point is printed previously
sprintf(newDispString, "%05.2f", newSpeed);
if (newDispString[0] != oldDispString[0]) {
prtDigit(oldDispString[0],10,SPEED_BASELINE, Display_Background_Color);
prtDigit(newDispString[0],10,SPEED_BASELINE, text_color);
}
if (newDispString[1] != oldDispString[1]) {
prtDigit(oldDispString[1],40,SPEED_BASELINE, Display_Background_Color);
prtDigit(newDispString[1],40,SPEED_BASELINE, text_color);
}
if (newDispString[3] != oldDispString[3]) {
prtDigit(oldDispString[3],90,SPEED_BASELINE, Display_Background_Color);
prtDigit(newDispString[3],90,SPEED_BASELINE, text_color);
}
if (newDispString[4] != oldDispString[4]) {
prtDigit(oldDispString[4],120,SPEED_BASELINE, Display_Background_Color);
prtDigit(newDispString[4],120,SPEED_BASELINE, text_color);
}
Well the thing is, adjectives such as "slow" and "fast" are relative to the own experience of the observer. Drawing is done by Adafruit_GFX and uses afaik the function drawPixel(). This draws pixel by pixel. Yes, drawing pixel by pixel is slow, even for your desktop PC / laptop. If you are refering the flash of the character when removed and drawed a new one, it is normal.
One thing you can check is, if you are using hardware SPI Interface. To more about Hardware SPI, read the docs: https://www.arduino.cc/en/Guide/TFT
Alternatively, if you are needing no color, you can consider buying another TFT without color.
I just find it odd because I've seen videos of similar ST7735 based displays, doing very fast animations...
And... 40 yrs ago the first PC clocked @ 4.77Mhz, the Nano 33 runs @ 64Mhz. I think is fast enough to do better, even with a serial interface like SPI.
Nano has 16 Mhz.
Ok again. I have the same display and using it with a MEGA 2560. I just watched some videos to confirm what you mean but it is the same performance I am getting with my setup. For example this one: Google for it
Arduino Tutorial: Using the ST7735 1.8" Color TFT Display with Arduino.
And since we have no reference beside your word "slow", we really can't say anything about that.
You may try UCGLib Libary. I read that it is slower but smoother so you think it is faster. But I have no personal experience in that.
I've seen that video before and mine is behaving definitely slower, hence my post.
Maybe I need to try another board...
PS - the nano 33 BLE runs at 64mhz
pjrebordao:
PS - the nano 33 BLE runs at 64mhz
Above a certain rate, processor speed is irrelevant. You become limited by the number of bytes you need to push and the capacity of the pipe you're pushing them through. Then there's the speed that the bytes can be processed by the device on the other end of the pipe.
The device on the other hand is not the problem imo. I have the same one and I am pretty satisfied. If you dont get the speed on that video, something is odd.
Don't know that board tbh. It is not documented here neither.
https://www.arduino.cc/en/products/compare
Try your TFT with another board Uno or Mega if possible and please share your resuls! 
Have a great one.
No comment on reply #2? It's important. Most display primitives only modify the buffer - it is not sent to the screen until you call the update method. That is because writing the whole screen takes much more time than just setting a pixel. Usually, there is no way to send commands directly to the display, you can only write the entire screen. So you are supposed to do a series of graphics commands, and only then send the buffer to the screen.
It's up to the programmer to figure out the most appropriate time and frequency of buffer writes.
Hey aarg, I think he answered that question indirectly at #4. He is obviously using the standard tft library which requires no manual updating.
What I would be interested in is pjrebordao, do you get similar results without .cursor() and instead of print() using text()?
Have a great one.
text()? I don't think I have that method in my GFX library...
Ugh we are getting closer now. I wonder, which TFT library you are using. Do you mind checking that up and if Not already, use the default arduino one? The link to the Ressource and doc is in #5
Have a great one.
I'm using the Adafruit GFX and ST7735 libraries downloaded through the IDE lib manager.
In the meantime, I've run the GFX demos on my board and they seem to run at the same speed as I've seen in videos, so maybe it was just a matter of perception.
But I think I see a difference regarding fonts when printing text.
If I use the standard / default font it seems to display faster than the custom fonts that I was using...