ST7735_t3/ST7789_t3 - LC Support Speedups?

KurtE

KurtE

Senior Member+
Since I had one of the T-LC chips out in breadboard to fix an issue with my partial LC support for the ILI9341 in my ILI9341_t3n library, I wondered about some of our other libraries for smaller displays and how well they were working.

So I thought I would grab one of the displays sitting on my desk in this case the 2" Adafruit ST7789 (240x320) and built the font output test.

I then remembered we have this library running on the LC, but it uses SPI.transfer or SPI1.transfer to do all of the outputs... So there is no double buffering of data going out over SPI and all 16 bit writes were done with two 8 bit writes... So I added a Serial out, with how long it took to draw the different font pages
(uint32_t displayStuff1())

I simply printed out the elapsed Millis a the end of the page:
Starting times were (Output modified to condense:
Code: 
Rotation: 0
Press anykey to continue

DS1 (0,90) 240 320
85
DS1 (0,90) 240 320
95
105
92
125
97
136
281
110
146
129
159
First pass, was to go to bypass SPI.transfer and instead try to go to register level and keep the SPI double buffer with data as much as possible. Still have to wait until queue is fully output before changing DC(RS) pin.

With This first pass, numbers are:
Code: 
Rotation: 0
Press anykey to continue

DS1 (0,90) 240 320
76
DS1 (0,90) 240 320
85
94
83
110
81
122
254
101
124
118
134
Question is, are there those out there using this type of setup? i.e. is it worth spending time speeding up these displays for the LC?
I put the WIP branch up at: https://github.com/KurtE/ST7735_t3/tree/TLC_Speedup

If I continue with this, may see if switching to 16 bit writes for pixels speeds up.
 
I went ahead and did the conversion to output 16 bit values when possible to again see the speed differences...
Code: 
Rotation: 0
Press anykey to continue
73
79
88
79
102
71
115
238
97
111
114
120
Again maybe not earth shattering change...

I pushed up the changes to the branch mentioned. Will see if anyone shows interest, and then issue PR.
 
Another quick check of speed differences, here is version of graphic test, adapted to show timing.
Existing released code:
Code: 
hello!ST7789_t3::init mode: 0
init

Set Rotation: 0
369

After fill screen

After test draw text

tftPrintTest: 2293
testlines: 3478
tftPrintTest: 521
testdrawrects: 464
tftPrintTest: 4255
testfill/drawcircles: 1327
testroundrects: 850
testtriangles: 511
mediabuttons: 1512
done

Set Rotation: 1
369

After fill screen

After test draw text

tftPrintTest: 2294
testlines: 3479
tftPrintTest: 520
testdrawrects: 500
tftPrintTest: 8626
testfill/drawcircles: 1328
testroundrects: 850
testtriangles: 536
mediabuttons: 1512
done
New:
Code: 
hello!ST7789_t3::init mode: 0
init

Set Rotation: 0
248

After fill screen

After test draw text

tftPrintTest: 2049
testlines: 2998
tftPrintTest: 352
testdrawrects: 314
tftPrintTest: 2864
testfill/drawcircles: 1136
testroundrects: 616
testtriangles: 382
mediabuttons: 1364
done

Set Rotation: 1
248

After fill screen

After test draw text

tftPrintTest: 2049
testlines: 2998
tftPrintTest: 351
testdrawrects: 339
tftPrintTest: 5800
testfill/drawcircles: 1137
testroundrects: 615
testtriangles: 413
mediabuttons: 1364
done
So not probably worth the update. Example the fill screen went from 369 to 248...
 
@KurtE
See you got back to playing with displays. Unfortunately have no idea where my one and only LC is so can't even give it a try.

But as you said not sure with these small displays if you draw a couple of rects or trianges will make much of a difference. Although not sure how much of difference there would be if you load bitmaps or try and run uncanny eyes (not sure if LC would work). Like i said dont know much about the LC.
 
I found with my teensy 3.2 and a 1.8 inch adafruit ST7735 screen 160x128 a bitmap loaded in 500ms using the spiftfbitmap example.If I overclocked the processor to 120mhz it loaded in 448 ms.Did you test how much faster spiftfbitmap works with the double buffering?

Carl
 
darebyvet said:
I found with my teensy 3.2 and a 1.8 inch adafruit ST7735 screen 160x128 a bitmap loaded in 500ms using the spiftfbitmap example.If I overclocked the processor to 120mhz it loaded in 448 ms.Did you test how much faster spiftfbitmap works with the double buffering?

Carl
Click to expand...

With T3.x - And you are using proper hardware CS pins in particular for DC pin, it will use the built in hardware FIFO queue. The double buffering comment was specific for LC, which before was working like the Adafruit library and just using SPI.transfer to do everything. And with SPI.transfer, nothing goes onto the SPI buss, until the previous transfer has fully completed, the return value (MISO) is returned to the calling code which in our case we ignore and then our code can push out the next byte. All of this time waiting for the return value to be processed and the layers code to unwind and then us output the next byte, the SPI queue is not active. So with this change, as soon as the system says it has moved the byte in the output register to the shift register, we can than put the next byte (or word) onto the shift register. Unlike T3.2, we do still have to wait for things to be fully output before we change things like the state of DC or if we are outputting one byte or two... But we do gain speed especially when doing things like fillRects, where we output lots of 16 bit values.
 
So If I understand you correctly if I am using the hardware SPI connections then the new code will not change the upload speed with my teensy 3.2 and adafruit screen. it is still more thna twice as fast as the Arduino Uno.The best speed I got was with an ESP 8266.I used the SPIFFs instead of the sd card and got 71 ms screen upload time with the processor clocked at 160 mhz. I read I can get 70ms using a teensy 4.0 using the flash memory to store the image.I am just not sure on the coding for the 4.0.
 
You must log in or register to reply here.
Back
Top