ILI931, rp2040, 8bit vs 16bit parallel performance ?

[joey120373]

I just finished wiring up a couple displays to play around with the new 16 bit option.
First display was a 480x320 ( ILI9481, but seems to work better when HX8753B is selected ) unit that I found on lcd-wiki, and it works great, very good performance, seems like a huge step up from 8bit mode or SPI.
Next I tried a 320x240 ILI9341 driver, and was kinda bummed, as using the 16 bit mode actually ran a bit slower than the same Ili9341 in 8bit mode, it’s still blazing fast, but is this normal? I used the same pin assignments for both the 9481 and the 9341 displays.
I would assume that the 16bit mode should be faster in any given case but on the smaller display it’s not, or am I doing something wrong.

Pin out :
RST. 27
TFT_WR 22
TFT_DC 28

TFT_D0 6
Through (Sequentially)
TTFT_D15 21
this isn’t a huge deal, as the ili9341 display is already faster than I need it to be in 8 bit mode.
What is really great now is that the 480x320 performance is really good.

Thanks

[Bodmer]

Different TFT controllers can cope with different write cycle timings, so since I have not tested the ILI9341 with 16 bit parallel (I do not have a suitable display) I have set the default to a longer cycle time.

You can see the speed constraining code here:
https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_RP2040.h#L89-L95

Try a value of 1 or 2 in this line:
https://github.com/Bodmer/TFT_eSPI/blob/master/Processors/TFT_eSPI_RP2040.h#L94

The TFT_graphicstest_one_lib example ususally shows up duff pixels at some point in the test if the cycle time is too small.

Let me know what works reliably.

[joey120373]

Thank you! I played around with it a little more and I was able to get slightly better performance out of the ILI9341 display in 16 bit parallel mode by setting the divisor to 1, and setting the CPU clock to 150MHz. Any faster CPU clock rates would cause issues with the display, more on that later.

That being the case, the overall performance ( at least on the PDQ graphics test ) was fairly on par with the same code in 8 bit parallel mode with the CPU clocked at 250MHz. Some of the tests ran about 10% faster, while others ran slower.

HaD push color was about 10% faster, while something like pixels was quite a bit slower, I don’t remember the exact numbers, but I can provide them if people are interested.

Overall, powering up both displays , at the same time, they reached the end of the scetch at essentially the same time, too close to call. I do want to set up and video a more conclusive test, but for the average user, no real difference. One nice thing is that the 16 bit mode will use about 10mA less current to run due to the slower clock speed, and that could be really important to some.
Also, though both TFTs use the same driver, they are not identicle screens, the 8 bit tft is from BuyDisplay, and the 16bit is one I found on LCDwiki, from Ali express or Bangood. I’m pretty sure that, at least in SPI mode, I can go quite a bit faster on the spi clock speed with the buy display unit, so I want to get one set up for 16 bit parallel mode and see if it will handle higher speeds than the Bangood one does.

For my application ( real time RS232 terminal ) ,the 8 bit mode seems to be a marked improvement over the SPI, though the SPI works well enough at any reasonable baud rate. The parallel mode just seems to scroll much smoother and will handle baud rated well above 115200.

[Bodmer]

The performance depends on the type of graphics operation. All commands and command register writes are always 8 bits parallel. To write a single pixel 11 x 8 bit commands/data register values are written (to set the graphics rectangle address window) followed by 1 x 16 bit pixel colour (two 8 bit writes or one 16 bit write), also the DC line must be toggled so there is almost no difference for a single pixel. Large pixel block writes such as fillScreen are where 16bits has the advantage, then 11 command/data bytes are written followed by "N" pixels, where N is large the overhead of the 11 bytes to set the window is tiny.

These are the results of running "TFT_graphicstest_one_lib" sketch on a 320x480 display with timing and totals, note that cycle time is saved if the CS line is NOT defined and the CS line is tied permanently low:

RP2040 16 bit parallel (32ns cycle time) HX8357C CS tied low (Block fill spreads time) DIV_UNITS 1
Benchmark,                Time (microseconds)
Screen fill (5 times),    20494  (243.97 fps)
Text,                     4219
Lines,                    43113
Horiz/Vert Lines,         1912
Rectangles (outline),     1128
Rectangles (filled),      50039
Circles (filled),         13823
Circles (outline),        15219
Triangles (outline),      10882
Triangles (filled),       20275
Rounded rects (outline),  5908
Rounded rects (filled),   51210
Total = 238222us
Total = 0.2382s

RP2040 8 bit parallel comparison to above
Benchmark,                Time (microseconds)
Screen fill (5 times),    40977  (122.02 fps)Block fills are half speed as expected
Text,                     4252
Lines,                    43143 Very similar (setAddr dominates)
Horiz/Vert Lines,         3542
Rectangles (outline),     2016
Rectangles (filled),      99956
Circles (filled),         14400
Circles (outline),        15225
Triangles (outline),      11016
Triangles (filled),       34911
Rounded rects (outline),  6558
Rounded rects (filled),   100667
Total = 376663us
Total = 0.3767s

Notice how fillScreen is nearly twice as fast, but individual pixel intensive graphics operations (that required the address window to be repeatedlt redefined) have little speed advantage. I would expect the ILI9341 to run nearly 2x faster for the screen fill as it has half the number of pixels.

[Bodmer]

Here are the results where DIV_UNITS is 2 and 3. The processor speed for all these tests (and those above) is 125MHz:

RP2040 16 bit parallel (64ns cycle time) HX8357B CS tied low (Block fill spreads time) DIV_UNITS 2
Benchmark,                Time (microseconds)
Screen fill (5 times),    39333  (127.12 fps)
Text,                     15007
Lines,                    67271
Horiz/Vert Lines,         13954
Rectangles (outline),     12230
Rectangles (filled),      10442
Circles (filled),         30375
Circles (outline),        20494
Triangles (outline),      25170
Triangles (filled),       53508
Rounded rects (outline),  18340
Rounded rects (filled),   131390
Total = 437514us
Total = 0.4375s

RP2040 16 bit parallel (96ns cycle time) ILI9481 CS tied low (Block fill spreads time) DIV_UNITS 3
Benchmark,                Time (microseconds)
Screen fill (5 times),    58997  (84.75 fps) (spreads into next test)
Text,                     20676
Lines,                    80092
Horiz/Vert Lines,         20900
Rectangles (outline),     18303
Rectangles (filled),      15654
Circles (filled),         42248
Circles (outline),        25008
Triangles (outline),      32361
Triangles (filled),       78724
Rounded rects (outline),  25251
Rounded rects (filled),   197152
Total = 615366us
Total = 0.6154s

[Bodmer]

Normally the library waits for a graphics function to finish before returning control to the sketch, since the PIO hardware handles writes to the screen it is possible to tell the library not to wait by putting tft.startWrite(); before a block of operations or even once after tft.init() in setup(). Then if a graphics function such as tft.fillScreen() is executed, the function returns immediately after setting the PIO registers. This means that the sketch runs on even though the fillScreen is still in progress. Since the PIO only has a small FIFO the driect write commands cannot be queued, so if a fillSCreen is followed by a drawPixel, then the drawPixel function will wait for the fillScreen to complete before it is executed.