SPI TFTs?

[james1095]

Has anyone tried driving one of those inexpensive SPI interfaced TFT displays that are all over? There are loads of them based on the ILI9341 and similar ICs. It would be great to have a chunk of code that could initialize the display and accept a standard digital R, G, B, H, V, dotclock interface. That would enable these cheap and readily available displays to be easily integrated into FPGA SOC designs. I've used them on a Raspberry Pi and they work well but FPGA is a whole different ball game.

[Jack Gassett]

I actually got one of those cheap TFT displays working with the Papilio in the past:

http://www.gadgetfactory.net/2011/10/experimentation-with-tft-touchscreens/

 

And Alvie sent me code once for a 2.2" SPI display but I never got a minute to test it out.

 

It should be easy to make DesignLab schematic symbols and Wings for both of these displays.

 

Jack.

 

2.2 SPI LCD.zip

[james1095]

I've gotten them working on Arduinos, that's easy with all the libraries that are out there but rather limited in what it can do and for that a $2.50 arduino clone works just as well with less fussing around than a $80 FPGA board. What I want is a lump of vhdl that will accept digital RGB data as would be sent to a VGA DAC, and pump out pixels to the TFT via SPI in real time. That would make it easy to use a small TFT with any code that was intended to drive a CRT monitor, retro gaming, computing, etc.

[Jaxartes]

I can see how such a converter would be useful.  I can think of some challenges it would have, namely:

 

Speed: If I understand the ILI9341 data sheet right, in serial mode it takes at least 16 bits per pixel, at most 10 million bits per second.  That's 625,000 pixels per second, much less than is sent over a VGA interface.  625,000 pixels/second = 8.14 frames/second for 320x240 frames.  It can handle more in parallel mode, but you'd need more wires (and the post was about SPI).

 

Memory: Admittedly, it doesn't really need to handle every pixel, every frame; most of the time they mostly don't change.  So the converter would detect what has changed, and transmit that.  It would keep a record, on the Papilio, of the pixels which have been sent to the display, and would send the differences.  That store would be, for 16bpp color, 128kB.  That's more than the FPGA on the Papilio has, so the converter would need access to the off-chip SRAM or DRAM, making it harder to use.  (4bpp color avoids this problem, and could be used for a lot of retro-gaming and computing.)

 

Logic: When the screen changes faster than the serial interface can handle, the converter would necessarily lag behind.  Depending on how it chooses which pixels to update, there might be unpleasant artifacts.

[james1095]

That's a good point, I think the Raspberry Pi driver does only send the data that changes, it's been a while since I've looked at that. Also these displays are 320x240 QVGA, so quite a bit lower bandwidth than VGA, I have an old CRT monitor that will sync to 15kHz so I often remove the scan doubler code and drive the VGA DAC with what is essentially CGA with analog RGB for arcade games and retro computer stuff.

 

While the low pin count of pure SPI is appealing, if it ends up needing external memory and a bunch of tricks to make it work, that would offset the advantage. Maybe it will just be necessary to use the dotclock interface in which case I'd just need to figure out how to send the required initialization and configuration commands over SPI to get the display in that mode.

 

There are other displays that have only an 8 or 16 bit parallel interface which sends the pixel values one color at a time, that would be a reasonable compromise of low pin count with high bandwidth.

[mkarlsson]

See this post in another topic thread:

http://forum.gadgetfactory.net/index.php?/topic/2295-driving-the-adafruit-5-800x480-tft-panel-with-an-fpga/?p=15865

 

I have free PCBs if anyone is interested.

[james1095]

I remember that thread, does that panel need to be initialized via SPI to get it into dotclock mode? I'll have to look at the TFTs I have to see if they have the same pinout, they're not the same as the one you used.

 

There used to be some really nice looking 2.4" AMOLED panels with a similar interface. I was excited to discover those but it seems they went out of production and nobody had any in stock by the time I tried to order one. A small 2-4" 4:3 QVGA AMOLED would be my holy grail miniature display device. I hate the low contrast and color distortion of LCD panels. Even good IPS panels have pathetic contrast ratios, despite the absurdly inflated specs on the matter.