I keep seeing various TFT LCDs on Aliexpress and similar websites for very good prices, they all use the ILI**** series LCD controllers and all support 16bit RGB communication, however I could not find a standard like that in any library for interfacing them as everything is in 4 wire SPI.
Can anyone direct me to some documentation or a library that uses this parallel interface for communicating with LCDs?
Thanks!
Surely the datasheets for the TFT modules themselves document the interface "per panel"? Just because a common controller is used it does not necessarily mean that the creator of the module has chosen to layout the chip/PCB/connectors in any "standard" way?
One of the first tests when buying something like this from Ali... or ebay is the very question of whether full documentation is available - I'd steer clear of anything not openly offering such PDF (or at least a link to a manufacturer website) as you are going to face all kinds of other issues if you don't have something telling you how to use it
EDIT: here's one I just picked completely at random in Google:
https://www.aliexpress.com/item/...
At least that has the good sense to show the 37 (?) pin connector layout but I'd still be a little concerned that it does not give much other detail unless they're assuming everything else one might need can be gleaned from the ILI9325/9328 manual?
Both Adafrut's TFT and UTFT can do parallel.
But for AVR's often only with an 8 bit interface, Most AVR's don't have many pins.
I have the UTFT demo running on an arduino mega2560, which has a 36 pin connector between the arduino and the TFT, but to be fair I haven't even looked at the code close enough.
UTFT is configurable for different interfaces and for different uC architectures.
I did not do very much with it because AVR's are a bit underpowered for controlling such TFT lcd's.
ARM Cortex 3 is a much better fit.
To get started started I want to advise to buy a complete set.
A complete set should have:
1). uC board.
2). TFT that fits on the uC board.
3). Software example(s).
A lot of combinations with STM32 are offered, (See below) but only a few have a promise for a software example download.
The board below does not seem to come with software, but you can always try to contact a seller before you buy.
https://www.aliexpress.com/item/...
If you search for "arduino tft kit" you get lot's of different offerings. Quite some of those seem to be built for the arduino mega 2560 and have enough pins for the 16-bit interface.
https://www.aliexpress.com/whole...
The TFT's which are pinned for the "arduino" versions with 2 single row headers are (often?) configured for an 8-bit interface.
(But those arduino's don't have a 8-bit databus and need bit banging / shifting. (See adafrut's "pinmagic.h" for some horrible macro's).
Here a link for a combination with the promise of example code on "cd rom E-mail transfer".
https://www.aliexpress.com/item/...
Note also that there are 2 urls printed on the back of the LCD, diving a bit deeper.
I found the same board on:
http://www.powermcu.com/product-...
Some comments about it "not working" 
I also see "Keil" which is a commercial compiler.
Commercial compilers often come with better support than GCC.
A lot of the STM32 development boards also have a connector which is labeled "TFT".
But if you want to go the Cortex 3 route then mbed is probably a much better place / forum to get your info.
If you want really nice documentation and a comfortable start one of the many mbed boards seems really nice.
But you pay for that. Just compare the documentation of a board like this:
https://os.mbed.com/platforms/LP...
It looks like a complete tutorial, with links to reference manuals & software & everything.
For the "cheap" route you can also watch some youtube vid's of demo's.
Search for a link to a website or software for more info.
Buy hardware from Ali / Ebay that looks like the hardware used in the youtube vid...
Here a direct link to UTFT:
http://www.rinkydinkelectronics....
UTFT comes with quite a lot of documentation in the .pdf's included in the download.
It also has several configurations and pinouts vor various 16-bit interfaces.
On github there are also 73 repositories reverencing "utft".
https://github.com/search?utf8=%...
Some of these might be tailored to a specific uC / Display / pinout configuration.
Yet another option is to buy a "dso138" oscilloscope kit.
It's got an stm32 and TFT display.
They claim to be "open source" but unfortunately jye tech is lying about that.
It's only partly open source and most of the display handling is in a pre compiled library blob.
https://github.com/search?utf8=%...
Yet another option is to play with an "DPS5005"
It's a switched mode power supply which can deliver upto 50V 5A and costs around USD30 on Ali.
There is3rd party open source software support for it through "opendps"
Thanks for the comments, a small development during the last few hours: The seller sent me a datasheet for the LCD. Almost everything is in Chinese, however the pin-out is available in a drawing:
And on the bottom of the page the controller model is listed as the ILI9488. Several connection diagrams are presented.
At this point I'm a bit confused as two different driving methods are presented by the datasheet and I think my lack of LCD knowledge is holding me back from "getting it".
According to the timing diagram is seems one communication method is for data & commands, the other involves vertical & horizontal signals in what looks like raster scanning the LCD.
For my specific application the 2nd would be what I am after but I'm not sure if this could be used simply as presented in a timing diagram or do I need to communicate commands using the 1st interface and "straight" display data through another?
I would like to point out that I wrote a library that drives an LCD with the ILI9341 controller over SPI that can display text in various sizes and draws geometric shapes but this is not what I am after here. I need this to display images, and if I can "dump" them by simply reading pixel data from file and sending it over that would be my choice. Is this an option here, it does look like it according to the datasheet.
For my specific application the 2nd would be what I am after but I'm not sure if this could be used simply as presented in a timing diagram or do I need to communicate commands using the 1st interface and "straight" display data through another?
Presumably the reason you are trying to use some kind of "wide" interface is for speed of update - are you planning to try and show moving video on the display and so need to be able to do 10..30 frame per second updates and that's why you need to dump tons of data at it in the shortest time possible? Because otherwise why not simply use a "thin" interface like I2C or SPI or similar?
If it is "moving video" at high frame rates and full panel resolution is a lowly AVR really the right chip to pick to drive such a thing when you could be using an ARM at 100's or even 1,000's of MHz?
Ah-ha. You have access to the IM# pins. So you can use whichever interface takes your fancy.
If you are familiar with Option3 (4-line SPI) in an ILI9381, the ILI9488 is very similar but note that you can only write to GRAM in 6-6-6 mode with the 9488.
Both controllers always read GRAM in 6-6-6 mode.
User Registers are identical. Manufacturer Registers are "similar" but require careful scrutiny of the differences.
If you are using Xmega or ARM, SPI with DMA is an attractive proposition. Read SD Card with SPI_DMA. Write to screen with SPI_DMA. Either with two SPI buses or sharing a single bus.
Parallel modes use an awful lot of GPIO pins. You either bit-bash or use an External Memory Bus e.g. Xmega-A1.
Parallel requires an enormous number of 3.3V level shifter channels if you choose a 5V MCU like ATmega2560.
David.
@clawson You are totally right and I do need something more beefy for a reasonable update rate - looking at an FPGA actually. As for the raw driving, as you call it, I understood the principle OK? It's raster scanning with various amounts of data according to what color depth you are interested in = how many bits per pixel?
The TFT I got working last week with the HX8357B on a TD-T320 display does not expose the IMx lines. It does however have 18 bit bus, the H and V sync along with the pixel clock exposed. My guess is that the SPI is intended for setting the Gamma etc and an FPGA would be used to have actually done the video refresh. The Display is also write only, which made debugging it a chore.
Also take note as mentioned above, these TFT displays are 2.8 to 3.3v and need level shifters if 5v logic is used!
I did not do very much with it because AVR's are a bit underpowered for controlling such TFT lcd's.
The video below is from a "DSO138"
A small scope like device with an STM32F103C8T6 (Which is quite a bit smaller and haf the clock frequency of the STM32F4xx.)
I have one (Bought it as a development board, not as a scope) and the screen update of the DSO138 is quite impressive.
https://www.youtube.com/watch?v=...
42 second demo of another board with TFT (Display via SPI).
