Port manipulation - LCD 8bit parallel

Working libraries, libraries being ported and related hardware
User avatar
RogerClark
Posts: 6907
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by RogerClark » Mon Jul 04, 2016 4:03 am

Thanks for posting an updated video

Re: SPI version

Yes.
Now I look at the code, there is loads of room for improvement, and like you said, even a few uS shaved off here and there in the low level functions make a big difference.

What is still slower for you is the fill stuff as you can't benefit from DMA. Well, if the pins were adjacent from the beginning of a port you could use DMA as you can DMA to GPIO (but we don't have any demo code for this)
But as you use pins all over the board, DMA will not really help :-(

User avatar
ahull
Posts: 1597
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by ahull » Mon Jul 04, 2016 10:03 am

iwalpola wrote:Yet another performance gain by inlining the write8special() function.
Demo (almost too fast to see):
https://youtu.be/sGU_wwX20hM

@Roger, there must surely be potential for improvement in the SPI code as well. What I learned today is that even microseconds worth of delay adds up fast when you repeat it 10000's of times.

Code: Select all

Benchmark                Time (microseconds)
Screen fill              320577
Text                     14869
Lines                    129592
Horiz/Vert Lines         25437
Rectangles (outline)     16493
Rectangles (filled)      666012
Circles (filled)         104502
Circles (outline)        96406
Triangles (outline)      30358
Triangles (filled)       230338
Rounded rects (outline)  41103
Rounded rects (filled)   709046
Done!
Neat! Screen fill is nearly five times (4.6 times) as quick as the earlier version. :D
- Andy Hull -

racemaniac
Posts: 517
Joined: Sat Nov 07, 2015 9:09 am

Re: Port manipulation - LCD 8bit parallel

Post by racemaniac » Mon Jul 04, 2016 1:54 pm

RogerClark wrote:Thanks for posting an updated video

Re: SPI version

Yes.
Now I look at the code, there is loads of room for improvement, and like you said, even a few uS shaved off here and there in the low level functions make a big difference.

What is still slower for you is the fill stuff as you can't benefit from DMA. Well, if the pins were adjacent from the beginning of a port you could use DMA as you can DMA to GPIO (but we don't have any demo code for this)
yes we do :p
http://www.stm32duino.com/viewtopic.php?f=18&t=1042

User avatar
RogerClark
Posts: 6907
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by RogerClark » Mon Jul 04, 2016 9:28 pm

Thanks

User avatar
RogerClark
Posts: 6907
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by RogerClark » Mon Jul 04, 2016 10:38 pm

@iwalpola

Can you post the code to your sketch that you use for those timing results, as I don't think its the same sketch that I am using to compare SPI speeds

(Or post a link to the sketch source code)

Thanks

Roger

User avatar
iwalpola
Posts: 24
Joined: Tue Jun 21, 2016 1:08 pm
Location: Silchar, India
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by iwalpola » Tue Jul 05, 2016 9:12 pm

RogerClark wrote:post code
graphicstest.ino
(9.15 KiB) Downloaded 57 times

User avatar
ahull
Posts: 1597
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by ahull » Tue Jul 05, 2016 10:03 pm

Code: Select all

Benchmark                Time (microseconds)
Screen fill              320577
...
Am I reading that correctly, the Screen fill test does 5 complete fills...

Code: Select all

unsigned long testFillScreen() {
  unsigned long start = micros();
  tft.fillScreen(ILI9341_BLACK);
  tft.fillScreen(ILI9341_RED);
  tft.fillScreen(ILI9341_GREEN);
  tft.fillScreen(ILI9341_BLUE);
  tft.fillScreen(ILI9341_BLACK);
  return micros() - start;
}
.. in 320577us ... or approximately 16 fps... ( 15.596876881 complete screen fills per second).. thats pretty impressive given the limitations of the hardware. I may need to fire up the oscilloscope sketch and try it with one of those displays. Given how little data is in a typical waveform, the higher refresh rate should actually be pretty useful. I suspect we should be able to achieve refresh faster than 50Hz, and possibly much higher.

One other thought. Since you have shown how to write parallel data very quickly, you should be able to read it at similar speeds, so an 8 or more channel logic analyser is another possibility. Roughly how many parallel writes per second do you think you are able to manage?
- Andy Hull -

User avatar
RogerClark
Posts: 6907
Joined: Mon Apr 27, 2015 10:36 am
Location: Melbourne, Australia
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by RogerClark » Tue Jul 05, 2016 10:27 pm

SPI is currently giving me these results

Code: Select all

Benchmark                Time (microseconds)
Screen fill              170787
Text                     22869
Lines                    241990
Horiz/Vert Lines         15802
Rectangles (outline)     11547
Rectangles (filled)      355060
Circles (filled)         142830
Circles (outline)        173697
Triangles (outline)      59139
Triangles (filled)       165883
Rounded rects (outline)  59967
Rounded rects (filled)   415460
Fills are much faster on SPI as its using DMA to write big chunks of data. Things which use single pixel access are half the speed, which I think its partially due to the unnecessary calls to setup the SPI before writing individual pixels etc

I'm not sure if it makes a big difference, but with SPI there is a completely wasted call overhead where the code calls an internal function called spi_write() which then just calls SPI.write()

I may just do a search and replace on this, as IMHO its pointless having an optimised library and still waste time doing this for compatibility with other platforms (when this version is STM32 hardware SPI only)

There is also some time repeatedly toggling the CS line before every write, which probably slows things down, - but I'm not sure by how much.

Well, I presume that its not necessary to toggle CS in this case, but I could be wrong, as I have worked with some devices that require CS to be toggled between each write block, but I think perhaps with the ILI9341 the CS line could be pulled low the whole time

User avatar
ahull
Posts: 1597
Joined: Mon Apr 27, 2015 11:04 pm
Location: Sunny Scotland
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by ahull » Tue Jul 05, 2016 10:32 pm

Its interesting to note that not everything is improved with DMA, line drawing and text for example appears to be slower.
Do we know what the absolute limits of the display are, in terms of speed?
- Andy Hull -

User avatar
iwalpola
Posts: 24
Joined: Tue Jun 21, 2016 1:08 pm
Location: Silchar, India
Contact:

Re: Port manipulation - LCD 8bit parallel

Post by iwalpola » Wed Jul 06, 2016 6:18 am

ahull wrote:Roughly how many parallel writes per second do you think you are able to manage?
I'm approximating from screen fill.
1 screen fill = 320*240px = 76800px
writes per pixel is 2 (2 times 8 bits), so writes per screen fill = 153600 writes
from screen fill benchmark, writes per sec = (5*153600)/0.320577 = 2395680 (2.3 MHz)
ahull wrote:Do we know what the absolute limits of the display are, in terms of speed?
Display refresh rate is around 50-70Hz, depending on the setting when initializing the display (either TFT::begin or TFT::init). GRAM abosolute write speed unknown, but must be pretty fast if it works with FSMC (not possible on my 48 pin STM32 but implemented elsewhere).

I just found a faster library written for Teensy @ https://forum.pjrc.com/threads/26305-Hi ... rary/page2 with more optimizations (the same kurt from arduino.cc is there lol)

Post Reply