notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Where do you want to see FBTFT go next?

Thu May 30, 2013 5:44 pm

https://github.com/notro/fbtft/wiki
Linux Framebuffer drivers for small TFT LCD display modules.
I have been working on this project for over 6 months now.
On the web statistics I can see that interest is picking up.
I'm not a user of this project my self, so I need help to find out what features/documentation are missing.

This is my current TODO list
  • Power management
    Most of the display controllers have deep sleep states. But there is no support for this in fbtft.
    This is important when powered by a battery.
  • Boot logo/splash screen
    Do some research on different solutions and try them out.
  • Improved touch calibration
    Forum post
  • PWM Backlight
    There is only support for on/off control of the backlight through fbtft. PWM support is missing because there is no pwm kernel driver.
    With PWM support in fbtft, apps that "know" brightness could control the backlight.
    It should be possible to use WiringPi to pwm the backlight outside of fbtft.
  • Gamma calibration
    All displays has a gamma curve that can be set. This controls the color brightness. Currently there's no way to adjust this, except for using the flexfb driver.
    One exception: @rm-hull has made a pull request for the itdb28fb driver. He has provided 6 curves to choose from.
    Is there an aplication that does this sort of calibration? Hopefully there is a standard somewhere to hook into.
    I have really wantet a tool that can adjust the gamma curcve on all different controllers. But it's difficult. Some has has only one curve, others two, one posisitive one negative.
    And the number of registers varies as well. And some registers is for a large adjustments, some for medium, and some for fine.
    How can I harmonize this is into an approach that fits all? What's the underlying pattern here?
  • Add more drivers. Which one?
    The challenge with larger displays (>3") is that they all have a 16-bit databus, which makes it hard to connect to the RPi with it's 17+4 GPIOs.
    It is possible, but leaves very few GPIOs for other peripherals. An alternative is to use an interface circuit: https://github.com/notro/fbtft/wiki/SPI ... ce-circuit
  • 16-bit databus support
    Currently only SPI and 8-bit databus is supported. I only have a rev. 1 board, so someone would have to work with me on this one (or I could buy a rev. 2 board ...).
  • Documentation
    Is parts of the current documentation weak, or altogether missing in some important areas?
    Any spesific improvements that can be done to make it easier for newbies?
  • Make it work on BeagleBone
    I have one on my shelf (not opened).
Feedback is welcome.

tap5
Posts: 9
Joined: Mon Apr 15, 2013 12:18 pm

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 12:13 pm

Hi Notro, thanks for your hard work with the fbtft driver.
I don't have any feature requests, I just wanted to say thanks. :D

ceteras
Posts: 239
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 12:30 pm

I think that using an expander for 16bit interfaces would be more elegant. Such as the MCP23S17 for SPI or MCP23017 for I2C.
But these chips only provide 16bit, and no control for WR and CS signals.
Still, could this be somehow implemented?

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 1:05 pm

tap5 wrote:Hi Notro, thanks for your hard work with the fbtft driver.
I don't have any feature requests, I just wanted to say thanks. :D
Thank you for the encouragement :-)

User avatar
elektrknight
Posts: 140
Joined: Sat Mar 02, 2013 1:25 pm

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 1:17 pm

Hi notro,

My subjective list of improvements in order of preference:

Improved touch calibration
I am working on interfacing 2.8" ILI9325 based LCD with touch and would love to have at least 3 point calibration support :-)

16-bit databus support and new drivers

I have been looking at a number of higher res LCD modules that use SSD1963. The resolutions start from 4.3" 480*272
up to 7" 800x480 with touch screen. The problem with this kind of resolution would be the update rate (fps).
From what I have seen in the data sheet the only way to talk to the SSD1963 is through 16-bit bus but would that be
enough to get a reasonable refresh rate? The proof is in the pudding so I guess I would have to plunk some money and get
one of those modules, any comments before I go and splurge on yet another LCD?


Power management
YES!

Documentation
Besides modules you have document there is couple others also supported that could be mentioned like the one
I have with ILI9325.
Placek Malinowy to jest to!

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 1:33 pm

ceteras wrote:I think that using an expander for 16bit interfaces would be more elegant. Such as the MCP23S17 for SPI or MCP23017 for I2C.
But these chips only provide 16bit, and no control for WR and CS signals.
Still, could this be somehow implemented?
I have looked into a lot of possible solutions, and this was one of them. What put me of was that Fclk max is 10MHz. That is slow, and as you said, additional logic is needed for WR. WR could be done in software, but that would slow it down even more.
The minimum Fmax for the 74HC4094 is 20MHz and typical Fmax is 58MHz. This enables us to max the Raspberry Pi SPI bus at 32MHz.
Frames per second drops as the display resolution goes up, so it's important to remove all the obstacles we can.
I have been thinking on trying out a 4-5" display with this interface circuit, but I'm afraid the throughput will be lousy.

But, of course there are many uses cases for these displays, and not all of them includes showing video.

Another solution to increase performance could be to use two 8-bit latches, and drive the display with a 8-bit bus.
The display would probably have a touch controller, so the SPI bus would have to be used.
So the GPIO budget would be:
SPI bus: 5 gpios
Databus: 8 gpios
WR: 1 gpio
Reset: 1 gpio (some controllers don't strictly need this)

Total: 15 GPIOS. If backlight should be controlled that would be 16 GPIOs.
That would leave 5 GPIOs available.

Would someone want such a setup do you think?

See here for some fps numbers: https://github.com/notro/fbtft/wiki/LCD ... ft-drivers

xtramural
Posts: 108
Joined: Thu Dec 29, 2011 11:16 pm
Location: Scotland

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 2:00 pm

notro wrote:
Another solution to increase performance could be to use two 8-bit latches, and drive the display with a 8-bit bus.
The display would probably have a touch controller, so the SPI bus would have to be used.
So the GPIO budget would be:
SPI bus: 5 gpios
Databus: 8 gpios
WR: 1 gpio
Reset: 1 gpio (some controllers don't strictly need this)

Total: 15 GPIOS. If backlight should be controlled that would be 16 GPIOs.
That would leave 5 GPIOs available.

Would someone want such a setup do you think?

See here for some fps numbers: https://github.com/notro/fbtft/wiki/LCD ... ft-drivers
I'd like to add my thanks to the work you've already undertaken. Regarding your question: I certainly would like to see a latched setup to get better FPS from the 3.2" screen. Am I right in assuming the 10FPS you've seen with that module is with the SPI at 16MHz and not the 32MHz? Ideally, a similar framerate (25FPS) to the ITDB02-2.8 with itdb28fb could be achieved. Would you need another GPIO to select between the LSB and MSB of the latch? It seems possible within the GPIO budget that's available.

Thanks again for your efforts - they are much appreciated.

ceteras
Posts: 239
Joined: Fri Jan 27, 2012 1:42 pm
Location: Romania

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 2:15 pm

I think for the databus you need one more GPIO for switching between the 8bit latches.
As far as I'm concerned, I prefer the solutions with the smallest parts count (and tracks count too).

Perhaps a 16bit latch could be used. Tie the two 8bits inputs together and control their latching with their separate controls.
See 74LVC16373A.
As long as the software is stable, I'd love to have such a solution.

User avatar
elektrknight
Posts: 140
Joined: Sat Mar 02, 2013 1:25 pm

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 5:22 pm

What put me of was that Fclk max is 10MHz. That is slow, and as you said, additional logic is needed for WR. WR could be done in software, but that would slow it down even more.
I think for the databus you need one more GPIO for switching between the 8bit latches.
Using standard logic chips puts a lot of limitations on the speed and with software switching GPIOs it is like hitting a speed wall.
Seems that increasing SPI speed is the only viable approach. On the RasPi side I would think SPI clk could be bumped to
at least 60MHz. To match that speed SPI to 16-bit parallel bus circuit could be implemented in CPLD device rather then
standard logic. But even then updating rate of 800x400 screen would be around 6fps under the best conditions.
Placek Malinowy to jest to!

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Tue Jun 04, 2013 11:55 pm

elektrknight wrote: Improved touch calibration
I am working on interfacing 2.8" ILI9325 based LCD with touch and would love to have at least 3 point calibration support :-)
Do you need a calibration tool, or is x_min/max, y_min/max not good enough?
The reason I'm asking is how "bad" are the common resitive touchpanels. The ITDB02-2.8 and Watterott M(something) worked fine with min/max. The Sainsmart 3.2 did not.
elektrknight wrote: 16-bit databus support and new drivers

I have been looking at a number of higher res LCD modules that use SSD1963. The resolutions start from 4.3" 480*272
up to 7" 800x480 with touch screen. The problem with this kind of resolution would be the update rate (fps).
From what I have seen in the data sheet the only way to talk to the SSD1963 is through 16-bit bus but would that be
enough to get a reasonable refresh rate? The proof is in the pudding so I guess I would have to plunk some money and get
one of those modules, any comments before I go and splurge on yet another LCD?
I have also looked into some SSD1963 based displays. And I don't think it will be enough throughput for video. What would you use such a screen for?
elektrknight wrote: Power management
YES!
How would you trigger sleep/resume and in what kind of setup do you need it?
elektrknight wrote: Documentation
Besides modules you have document there is couple others also supported that could be mentioned like the one
I have with ILI9325.
Yes, there's a lot of displays that is supported by some fbtft driver. To not loose myself in this documentation task, I think I will create a wiki page for displays that work with a certain driver.
It's a bit hard to cram lots of information on these wiki pages, they become hard to maintain.
Could you give me some details about the displays?

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Wed Jun 05, 2013 12:01 am

xtramural wrote: Regarding your question: I certainly would like to see a latched setup to get better FPS from the 3.2" screen.
Am I right in assuming the 10FPS you've seen with that module is with the SPI at 16MHz and not the 32MHz?
Ideally, a similar framerate (25FPS) to the ITDB02-2.8 with itdb28fb could be achieved.
Would you need another GPIO to select between the LSB and MSB of the latch? It seems possible within the GPIO budget that's available.
The Sainsmart 3.2" display didn't handle 32MHz. The same conclusion as @valdodov came to.
The SPI Controller driver that comes with fbtft, can set SPI speeds in more steps than the vanilla driver which only does 2, 4, 8, 16, 32MHz.
I tried the Sainsmart display at 24MHz, but I got pixel errors.

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Wed Jun 05, 2013 12:48 am

ceteras wrote:I think for the databus you need one more GPIO for switching between the 8bit latches.
As far as I'm concerned, I prefer the solutions with the smallest parts count (and tracks count too).

Perhaps a 16bit latch could be used. Tie the two 8bits inputs together and control their latching with their separate controls.
See 74LVC16373A.
As long as the software is stable, I'd love to have such a solution.
elektrknight wrote: Using standard logic chips puts a lot of limitations on the speed and with software switching GPIOs it is like hitting a speed wall.
Seems that increasing SPI speed is the only viable approach. On the RasPi side I would think SPI clk could be bumped to
at least 60MHz. To match that speed SPI to 16-bit parallel bus circuit could be implemented in CPLD device rather then
standard logic. But even then updating rate of 800x400 screen would be around 6fps under the best conditions.
OK, databus and throughput.

SPI
With the vanilla SPI Controller driver spi_bcm2708, the maximum speed is 32MHz.
With the driver that comes on the fbtft image, a limitation is lifted, so the max speed I get with a loopback wire is 48MHz.
The problem then becomes, what chips can handle this speed?
The 74HC4094 is probably on a limb here, I haven't tested it.
CPLD is something I looked into, but they are all smd, and the breakoutboards are expensive. And then we have the the task of programming them.
For myself, I pursue a solution most people can implement on a prototype board. I'm not planning to sell PCBs.
Here is a comment by Gert about SPI speed: http://www.raspberrypi.org/phpBB3/viewt ... 86#p230386

Parallel
I'm going to implement 16-bit support. It's easy to do, and even if I can't test it myself, I can't go much wrong on that.
I guess someone could test this with the Sainsmart 3.2" display and give us some fps numbers.

The 74LVC16373A is smd as far as I can tell. How can I do that chip on a protoboard?

I really don't like soldering, so doing a lot of hardware prototyping is not my cup of tea. But I do like writing software that drives hardware :-)

This really brings up the question about the DSI port. They have probably started working on it, but who can say how long it takes. The camera module took one year.
But as @jamesh says, the foundation has tech people employed now.
DSI will solve the throughput problem, at least for the display sizes we are talking about. Maybe then fbtft will be a purely SPI display solution.

Is 5" 16-bit databus displays cheaper than RCA ones, since there's an interest in this?

User avatar
J0HN
Posts: 14
Joined: Wed Jun 05, 2013 8:51 pm
Location: the Netherlands

Re: Where do you want to see FBTFT go next?

Wed Jun 05, 2013 9:33 pm

Hi,

To me it looks like the SSD1963 controller can be set to 8 bit data bus width by software so no need for soldering and changing jumpers on those delicate flex PCB's, if possible at all.
See http://www.allshore.com/pdf/solomon_systech_ssd1963.pdf look for page 16 and 75
If this is really true, than it can be easily wired up to the RPi and controlled by 'flexpfb' without any extra hardware to add.
And speed wise it would be possible to even drive those nice 5" 800x480 displays.
Have also a look for "ssd1963 800x480" on google you can find some really good deals.

-John

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Wed Jun 05, 2013 10:58 pm

J0HN wrote: To me it looks like the SSD1963 controller can be set to 8 bit data bus width by software so no need for soldering and changing jumpers on those delicate flex PCB's, if possible at all.
See http://www.allshore.com/pdf/solomon_systech_ssd1963.pdf look for page 16 and 75
If this is really true, than it can be easily wired up to the RPi and controlled by 'flexpfb' without any extra hardware to add.
Yes, you seem to right about that being configurable. But the 8-bit mode is a special one.
In framebuffer video memory the pixels are stored as RGB565. Red has 5 bits, Green has 6 bits and Blue has 5 bits = 16 bits per pixel.
The SSD1963 16-bit (565) mode accepts the pixels as is.
In 8-bit mode one pixel is sent as 3 bytes: R6 + G6 + B6. We also would have to convert RGB565 to RGB666.
This is a 50% drop in throughput not counting the conversion time (2 bytes vs. 3 bytes per pixel).

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Wed Jun 05, 2013 11:20 pm

At least I don't see any point in going for 7" displays with FBTFT when a 7" HDMI display can be had for $61: http://www.raspberrypi.org/phpBB3/viewt ... 64&t=43778

Searching ebay for "ssd1963 800x480" gives me 5" TFT displays around $40-50 incl. shipping. In addition to this we have to add some kind of PCB (strip board) and some chips and the time to solder and troubleshoot.

Is it the touch panel that gives the TFT panel an advantage?

User avatar
elektrknight
Posts: 140
Joined: Sat Mar 02, 2013 1:25 pm

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 3:11 am

notro wrote:At least I don't see any point in going for 7" displays with FBTFT when a 7" HDMI display can be had for $61: http://www.raspberrypi.org/phpBB3/viewt ... 64&t=43778
7" HDMI means adding another large driver board + power supply (extra power!) + more cabling and
all the unnecessary connectors and there is question of the the video quality.
notro wrote: Searching ebay for "ssd1963 800x480" gives me 5" TFT displays around $40-50 incl. shipping. In addition to this we have to add some kind of PCB (strip board) and some chips and the time to solder and troubleshoot.
To me adding a simple interface board is not a big deal.
notro wrote: Is it the touch panel that gives the TFT panel an advantage?
Touch is nice to have.
Placek Malinowy to jest to!

User avatar
elektrknight
Posts: 140
Joined: Sat Mar 02, 2013 1:25 pm

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 3:25 am

notro/ wrote: I have also looked into some SSD1963 based displays. And I don't think it will be enough throughput for video. What would you use such a screen for?
I need a nice quality display for HMI application. Full screen video is not really needed, but it needs to have enough throughput
to continuously update about 30% of the screen area. Oh and it needs to be easily interfaced too. DSI seems to be an option
but for now it is still the future one. Although there seems to be some hope, at least as far as finding some quality and
inexpensive displays is concerned http://www.raspberrypi.org/phpBB3/viewt ... 6&p=356536
Placek Malinowy to jest to!

User avatar
J0HN
Posts: 14
Joined: Wed Jun 05, 2013 8:51 pm
Location: the Netherlands

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 8:29 am

notro wrote: In 8-bit mode one pixel is sent as 3 bytes: R6 + G6 + B6. We also would have to convert RGB565 to RGB666.
This is a 50% drop in throughput not counting the conversion time (2 bytes vs. 3 bytes per pixel).
I see your point.
Is the frame buffer always in a [email protected] layout, or can it be defined in other layouts without taking to much of RAM?
Maybe it is better to use a extra hardware latch to load first byte as mentioned earlier, which gives us only a 50% drop of performance.
If we only had some more direct IO... ;)
Attachments
TFT.png
TFT.png (23.65 KiB) Viewed 11249 times
Last edited by J0HN on Thu Jun 06, 2013 10:12 am, edited 1 time in total.

texy
Forum Moderator
Forum Moderator
Posts: 5160
Joined: Sat Mar 03, 2012 10:59 am
Location: Berkshire, England

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 10:03 am

Keep up the good work Notro. I know I wouldn't be seeing as much interest in my lcd shields if it wasn't for the fbtft drivers ;)
And I know you are already working on HY28A-LCDB support (ILI9320)...
Although slightly off-topic, I would also like to be able to redirect the rapsistill preview output to fb1 - that would be really useful.

Texy
Various male/female 40- and 26-way GPIO header for sale here ( IDEAL FOR YOUR PiZero ):
https://www.raspberrypi.org/forums/viewtopic.php?f=93&t=147682#p971555

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 11:58 am

J0HN wrote: Is the frame buffer always in a [email protected] layout, or can it be defined in other layouts without taking to much of RAM?
The framebuffer subsystem supports this. RAM is no issue. But then a vmem_write() function has to be made to handle this. And I'm not sure how well RGB666 is supported by applications?

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 12:00 pm

J0HN wrote: If this is really true, than it can be easily wired up to the RPi and controlled by 'flexpfb' without any extra hardware to add.
You are probably right about flex(p)fb. SSD1963 uses the same registers to set the update area as the default fbtft set_addr_win() function does.

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 12:08 pm

I have tried to do some estimates on throughput for a 800x480 display. Correct me if I'm wrong.

Throughput formula: Resolution x 2 bytes per pixel x fps = bytes/second

Measured throughput
ITDB02-2.8 8-bit parallel: 240x320 x 2 x 25 = 3.84 MB/s
ITDB02-2.8 8-bit bus using SPI @32MHz: 240x320 x 2 x 17 = 2.61 MB/s
Sainsmart 3.2, 16-bit bus using SPI @16MHz: 240x320 x 2 x 10 = 1.54 MB/s
Sainsmart 3.2, 16-bit bus using SPI @32MHz: 3.1 MB/s (not measured, the display doesn't work at this speed)

Source: https://github.com/notro/fbtft/wiki/LCD ... ft-drivers

Theoretical 800x480 throughput
8-bit parallel: 3.84 MB/s / 800x480 x 2 bytes = 5 fps (latching time is not considered)
16-bit parallel: ~10 fps
SPI @32 MHz: 3.1 MB/s / 800x480 x 2 bytes = 4 fps

One thing to consider is that if the touch panel is to be used, this probably needs the SPI bus, which favours the SPI interface circuit.

Does anybody know how fast a display has to be for X applications to be usable (not movies)?

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 12:45 pm

texy wrote: Keep up the good work Notro. I know I wouldn't be seeing as much interest in my lcd shields if it wasn't for the fbtft drivers ;)
And I know you are already working on HY28A-LCDB support (ILI9320)...
Thanks Texy :-)
I have wired up the display, and @topogigio's library brings it to life. Now I have to find out how to implement the Start byte thing this controller needs.

User avatar
J0HN
Posts: 14
Joined: Wed Jun 05, 2013 8:51 pm
Location: the Netherlands

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 1:20 pm

notro wrote:One thing to consider is that if the touch panel is to be used, this probably needs the SPI bus, which favours the SPI interface circuit.
If you are using a rev.B board you can consider moving some IO over to P5 (GPIO28-31) to free up the SPI bus again.
This way the SPI bus is not shared for display and touch, probably touch needs to work under IRQ and interrupts the LCD operations.
notro wrote:Does anybody know how fast a display has to be for X applications to be usable (not movies)?
Well things are never fast enough obviously but it depends on the use of it.
I would not mind if it can be used for status and terminal use so I tend to go towards resolution over speed, the more info can be presented at once the better so leave X running on HDMI or later on DSI.
At the same time consider the energy use and portabillity also keep in mind that most of us already have a PC running Ubuntu or something else for the more demanding jobs.
But most importantly... don't forget the kick of making it all to work. :D

notro
Posts: 695
Joined: Tue Oct 16, 2012 6:21 pm
Location: Drammen, Norway

Re: Where do you want to see FBTFT go next?

Thu Jun 06, 2013 1:58 pm

J0HN wrote: If you are using a rev.B board you can consider moving some IO over to P5 (GPIO28-31) to free up the SPI bus again.
This way the SPI bus is not shared for display and touch, probably touch needs to work under IRQ and interrupts the LCD operations.
Yes, you're right about touch cutting some performance if they use the same bus. Not sure how much it is though. But it does costs CPU, because while dragging the pen I can see how the CPU usage spikes.

When I get the time to add 16-bit write support, someone could start testing with a SSD1963 display to give us some real performance numbers to look at.
Starting with a 16-bit bus is also a good in the sense that it is easy to hook up, which makes troubleshooting simple.
First we make the SSD1963 work with FBTFT, then we can look at other bus alternatives.
J0HN wrote: But most importantly... don't forget the kick of making it all to work. :D
You're absolutly correct. That sums it up :ugeek:

Return to “Other projects”