Electronic – TFT LCD interface with a Microcontroller: Getting Started

This is going to be an extremely tedious project to get working.

Here's how to do it, though:

1. Sample the composite video signal at 5.5 MHz (the bandwidth of composite video) using a high-bandwidth ADC.
2. Look for the line sync pulse. Once you've got that, you have a line of video in your buffer.
3. Looking in your buffer, find the colorburst section of the data. This will let you split up the data into the two parts (luminance and chrominance)
4. Since your LCD is a 160 pixels long, bin the luminance signal into 160 bins.
5. Average each bin's value. This is the value of the luminance at that pixel.
6. The color burst is going to be tricky. You're going to need to demodulate the quadrature encoded signal into the two color signals by looking at the phase differences of the signals. That's going to be some hardcore DSP. Once you're done with that, you have your two extracted color signals.
7. Repeat the binning process for the first extracted color signal. This is your Cb signal.
8. Repeat the binning process for the second extracted color signal (the one that's quadrature-encoded). This is your Cr signal.
9. Repeat this process for each line of video until you get to the end of the field.
10. Now, you need to repeat this for the next field. Remember that NTSC composite sends video interlaced, and not progressive.
11. After this is done, you should have an array of CIE YCbCr values that is 160 pixels wide by about 525 lines tall.
12. You need to compress the lines of video down to 128 (the height of the display). Average over the vertical column in your pixel array to find the separate Y, Cb, and Cr values for each pixel.
13. Since your display uses RGB instead of CIE YPbPr, you'll need to convert each pixel to RGB. There's fixed-point formulas available that are optimal for doing it on a computer.
14. As soon as you've got the RGB array, you'll need to write the data out to the display using the SPI interface. The display will have a protocol that explains how to write data to it.

Pitfalls

• By averaging and binning the pixels without doing bicubic or any other sort of smart sampling, you're going to get terrible aliasing that makes the video look jaggedy and weird.

• Since it's doubtful that your SPI clock is fast enough to write data to the display fast enough, you'll experience dropped frames. You'll need to ensure your controller can deal with that.

Other ideas

Don't reinvent the wheel. eBay sells a ton of wearable displays (with small screens) with composite inputs. I'd start with something like that and hack it to fit your application. Just remember to remove the optic in front of the piece that throws the image further away to make it easier for your eye to focus on (unless you want that, that is...)

The INT057ATFT uses an SSD1961 controller, whose I/O can be configured in Motorola 6800 mode or Intel 8080 mode. So if your microcontroller has an 8080 type interface you can connect it without problems. But also a microcontroller without external address or data bus can talk to the LCD controller, of course.

The left side connections are the only ones you should look at. The ones on the right are the controller's business; you don't have to worry about those. That's very different from the TM056KDH01 you refer to in a comment. That's an LCD controller which needs continuous data, combined with vertical and horizontal sync. You can compare it somewhat with video + sync: if you stop supplying a video signal you won't have a picture. Only here you have 18 digital lines instead of one analog. The SSD1961's microcontroller interface runs asynchronous of the LCD refresh. You just have to fill the buffer.

There are a couple of control lines, like D/C (Data/Control) select, R/W and enable, which will be familiar for users who have worked with text LCD modules with a 44780 controller. The SSD1961 datasheet has a list of commands you can use to configure the LCD. You supply the commands via the 18-bit data bus. That allows to send a complete pixel data of 3 x 6 bit (RGB) simultaneously. An 8080 microcontroller only has an 8 bit bus, and you can configure the device to use only 8-bit; the unused data lines should remain floating. In 8-bit mode you need less I/O pins on you microcontroller, but each pixel will need three successive writes.