iamalien
Posts: 3
Joined: Sun Oct 18, 2015 1:51 pm

Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 12:44 pm

Hello guys, i bought a really cheap display having resolution 176x220 and is of 2.2" (3.2$ on aliexpress), and as expected there was no datasheet or driver provided with it or any description of the controller or its name. So, after some search i was able to get hold of the name controller which was S6D0164, so i wrote the display driver using SPI reading its datasheet, but it didn't work for some reason. Then i wrote the display driver using 8bit parallel line and that worked, displayed images and videos and then displayed the default framebuffer onto it by changing its resolution to 220x176.
So, it all works, but the problem is that there is ~25% constant CPU usage when the program is running. I have made the driver in C++(mostly C, but 1 or 2 functions of C++), used wiringPi for GPIO access, will change it to direct register access when the high CPU usage problem is solved, although the current refresh rate is good too.
So i guess it is probably the GPIO access that is eating the CPU since it constantly keeps refreshing the display, so what should i do to decrease the CPU usage? (tried decreasing refresh rate, still same CPU usage) Will direct GPIO register access be able to help me here to decrease CPU usage?

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 2:55 pm

Well, without seeing the source code could only start guessing... I would assume the CPU is used by your driver looping and pushing the data through GPIO.
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

iamalien
Posts: 3
Joined: Sun Oct 18, 2015 1:51 pm

Re: Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 3:28 pm

I decreased the refresh rate even more and now it seems that decreasing the refresh rate decreases cpu usage since it gets that much free time by not updating gpio(i will go on till there is no tearing). So is there any way we can minimize the gpio cpu usage in any way?
(btw i am doing this the normal way, i.e. taking framebuffer and mapping it to memory and then just sending the values to display with another function, so nothing special happening here)
(also -rst-, i waned to say thanks to you for your first blog post where you told about getting info of the framebuffer :P i stumbled upon your blog when i was searching for ways to access framebuffer data, i feel it should be made sticky or added to a new thread containing useful blog links so its not hard to find for new users who want to work with it)

-rst-
Posts: 1316
Joined: Thu Nov 01, 2012 12:12 pm
Location: Dublin, Ireland

Re: Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 5:31 pm

How do you access the GPIO (which library, protocol etc)?
http://raspberrycompote.blogspot.com/ - Low-level graphics and 'Coding Gold Dust'

iamalien
Posts: 3
Joined: Sun Oct 18, 2015 1:51 pm

Re: Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 5:41 pm

right now i am using wiringPi library, but would switch to direct register access once my exam is over, it should probably decrease the cpu usage

User avatar
AndyD
Posts: 2334
Joined: Sat Jan 21, 2012 8:13 am
Location: Melbourne, Australia
Contact: Website

Re: Framebuffer to TFT consuming lot of CPU

Wed Feb 10, 2016 9:09 pm

One way to reduce the CPU usage would be to save the framebuffer to memory. Then you could compare the current screen buffer to the previous image and only write pixels to your display that have changed.

dradford
Posts: 18
Joined: Mon Feb 15, 2016 3:33 pm

Re: Framebuffer to TFT consuming lot of CPU

Mon Feb 15, 2016 3:58 pm

The really nice thing about using SPI0 is that it can be fed directly from dma, and so your only cpu hits will be at the start and end of transfer, once per frame. (Of course, the extra bus traffic can slow down memory accesses by the cpu, but that's always going to be the case.) I'd urge you to revisit the spi approach and get that working - I've been doing that in bare metal stuff. Then convert it to use dma.

With the dma method you need to send an initial word to the fifo to set up the transaction, then the remaining words are raw data. To dump a whole framebuffer, you'd probably want to chain two dma blocks together - the first writing the control word and the second dumping the framebuffer. (Also, you need to set up TWO dma channels - the peripheral manual explains it all.) You'll need to use bus addresses of course. Then you just set SPI0 to dma mode, set the two channels running, and wait for the dma interrupt to signal completion.

Are you using the right SPI interface? There are 3: SPI0 is the main one (the one you'd probably want for driving a display); SPIs 1 and 2 are part of the auxiliary block (which confusingly names them 0 and 1 in its register list). Have you set the clock divider correctly? And selected the correct data format - it can do 8-bit, 9-bit lossi, and either 24 or 32 bit (I forget which offhand). Did you set the gpio spi pins correctly?

Can't think of any other common mistakes right now.

iamchaucy
Posts: 3
Joined: Mon Apr 03, 2017 9:39 pm

Re: Framebuffer to TFT consuming lot of CPU

Wed Apr 05, 2017 7:29 am

iamalien wrote:Hello guys, i bought a really cheap display having resolution 176x220 and is of 2.2" (3.2$ on aliexpress), and as expected there was no datasheet or driver provided with it or any description of the controller or its name. So, after some search i was able to get hold of the name controller which was S6D0164, so i wrote the display driver using SPI reading its datasheet, but it didn't work for some reason. Then i wrote the display driver using 8bit parallel line and that worked, displayed images and videos and then displayed the default framebuffer onto it by changing its resolution to 220x176.
So, it all works, but the problem is that there is ~25% constant CPU usage when the program is running. I have made the driver in C++(mostly C, but 1 or 2 functions of C++), used wiringPi for GPIO access, will change it to direct register access when the high CPU usage problem is solved, although the current refresh rate is good too.
So i guess it is probably the GPIO access that is eating the CPU since it constantly keeps refreshing the display, so what should i do to decrease the CPU usage? (tried decreasing refresh rate, still same CPU usage) Will direct GPIO register access be able to help me here to decrease CPU usage?
i'm also having trouble with this lcd, do you have any idea about how to wire the pins?

Return to “Graphics programming”