TFT LCD Version 2 « LeafLabs Garden

LeafLabs Garden » Community » The Garden

TFT LCD Version 2

(9 posts) (5 voices)

Started 4 years ago by pra
Latest reply from Vidales

pra
Member

For some obscure reason I seem to have gotten onto a LCD kick. My latest endeavor has been interfacing an Embedded Artist's 320 x 240 display to the Maple. This device is made by a swedish company but available from Digikey for about $115. It has a SPI interface, along with parallel. I kept the library functions mostly compatible with my Adafruit version, with some additions to accommodate display features such as PWM controllable backlighting, display inverse etc.

An interesting and challenging addition with this LCD is a touch screen. This is also SPI based but is not compatible with the LCD itself clock speed wise. The LCD runs with a maximum SCLK of 13 MHZ, and won't work at anything slower than 4.5MHZ. The Touch Screen cannot work with anything faster than 2 MHZ. They both share the same MOSI, MISO, and SCLK connections with separate chip selects.
So I have to flip the hardware SPI speed between 1.125MHZ (Touch Screen) and 9 MHZ (LCD) depending on what I'm accessing at the time. Fortunately, the Touch Screen has an option to generate an interrupt when the screen is touched, so I run in LCD by default.

The other issue with Touch Screen is aligning the x,y AD values of a touch with an actual screen coordinate. The defacto industry standard for this calibration is Carlos E. Vidales' "calibrate.c", kindly provided by Embedded Artists even if the sample "howto" is based on some obscure microprocessor and operating system and not very helpful. I have the calibrate function working, in than I can sort of align touches with screen coords, even though my stubby fat fingers and touch screens are basically incompatible. What I haven't figured out yet exactly is how to save off this alignment and matrix transformation info and reuse it in a meaningful application.

So I guess I now have two options for user input/output with my Maples. Cheap - Adafruit 1.8" TFT LCD ($25), IR Sensor/decoder chip ($2.00) and Adafruit Remote Control ($5.00) or expensive - LCD with Touch Screen ($115.00)...and of course I can always use the IR Remote with the bigger LCD instead of/or in addition to the Touch Screen.

Posted 4 years ago #
BruceF
Member

Have you looked at the Adafruit 2.8 TFT Touch Shield?

http://www.adafruit.com/products/376

Posted 4 years ago #
pra
Member

I've looked at it. I don't like that it uses every I/O pin, no serial interface.

Posted 4 years ago #
pra
Member

Rechecking the adafruit offerings, they have a version of this same 320 X 240 display that doesn't have the Arduino shield interface. The datasheet for the controller indicates that it has a SPI serial interface, so I will give it a try. It's a lot cheaper ($40) than the Embedded Artist version.

By the way, the display I have paints fine over a serial interface at 9 MHZ.

Posted 4 years ago #
robodude666
Member

pra, I wouldn't recommend wasting your time with SPI on a QVGA LCD. The performance is just not fast enough.

The QVGA LCD has 320 x 240 pixels, with 16 (or 18 bits - technically 8 also but that's only 256 colors) per pixel. That's 1,228,800 bits using 16-bits per pixel. With a 9 MHz SPI interface, you can send roughly 9 million bits per second. That's roughly 137 milliseconds to update a single frame of the LCD, or a 7 Hz refresh rate. That excludes all of the commands in between writes to setup the row/column you're writing to and configuring for GRAM access. You'll realistically get a < 6 Hz refresh rate.

I have a similar LCD, and with a 8-bit parallel interface I'm getting great results depending on what type of data is being written. I'm in the process of writing a good library for it that I will publish in the future. I'm currently focused on some other projects (wirish DMA, and DataFlasj libraries) but will return to this again in the future.

If you do decide to get this LCD, or a similar one, take note that the interface they communicate over is configured via hardware pullup/pulldown connections and software register configuration. The boards Adafruit sells, along with the rest of the world -- i.e. any QVGA LCD you'll find -- is configured for 8-bit or 16-bit parallel. If you wish to use one of these via SPI, you'll need to cut a trace and solder a tiny jumper wire to make the appropriate hardware setting.

The embedded artists board is the only board I've seen that is configurable and is of decent quality. I own a cheap $50 chinese/thai clone, and it works, but it's certainly not the same as owning a good board.

-robodude666

Posted 4 years ago #
gbulmer
Moderator

pra - there are two SPI interfaces on the STM32F103RB.

Would it be easier to wire one SPI to the display, and the other SPI to the touch screen?
Then there is no flipping of its configuration to match the device, and it may be easier to DMA out to the LCD.

Posted 4 years ago #
pra
Member

I know - it just seems to me that a 2nd SPI channel could be more gainfully employed than just touch screen processing :-). To use DMA for output (and to gain any value from doing so) , I need to rewrite the library API (currently an adaptation of the Embedded Artists and Adafruit code) so that it sends multiple pixels at a time, rather than the current single pixel to the display at a time. I feel the speed of the 320 x240 display at 9 MHz is quite adequate, certainly fast enough for my purposes

Posted 4 years ago #
pra
Member

Robodude66 - Thanks for the advice. As noted above, the EM LCD works fine for me over SPI. I got the Adafruit one ($40) and it's worse that you said - the only connections exposed to pins is for 8-bit parallel, so even though the controller supports SPi, the pins are not exposed and the chip is surface mount. So this device goes into the spare parts box until I get around to playing with a parallel version...and even there, the EM supports both 8 and 16 bit, so I'd probably use it instead...and as you say, a quality board versus a knock-off.

Posted 4 years ago #
Vidales
Member

pra,

Thanks for the flattering comments that "The defacto industry standard for this calibration is Carlos E. Vidales' 'calibrate.c' " I certainly would like to believe so.

The original article and sample code was published by the now defunct Embedded Systems Journal, but the article & sample code (not CPU specific) still lives at http://www.embedded.com/design/embedded/source-code/4209764/06vidales-zip

Else, send me a note and I will be glad to provide the sample code.

Enjoy.

Posted 2 years ago #

RSS feed for this topic

Reply

You must log in to post.