3.2 TFT touchscreen

So I’m looking at a 3.2" TFT touchscreen (http://www.ebay.com/itm/3-2-inch-TFT-LCD-module-Display-with-touch-panel-SD-card-240x320-than-128x64-lcd-/200908823757?pt=LH_DefaultDomain_0&hash=item2ec7195ccd) for a controller project.

I’d like to run the finished unit off of a atmega328, as I already have some lying around. The problem, however, is that this comes with a 16-bit parallel interface. Then there’s the touch pins, and the SD card pins (which I could live with out if I need to save pins). So between those it eats up pretty much all the pins on the 328.

I’m aware that the driver on it, the ssd1289, supports 3 and 4 wire serial. However, according to this Sprites mods - Connecting an LCD to a non-video-capable Linux device - Hardware, the boards do not bring the jumpers for the controller out to anything that can be used. So it’s stuck with the default 16-bit interface.

My next thought is to run it off a shift register, similar to how the guy in the spritemods link did it. I’m concerned, though, how slow the display would be. I’ve read people having it take 4 seconds to clear the screen in similar configurations. All I need it to do is display some text data streams, static images, and run a couple sliders. So my needs aren’t too demanding on it, so it might work this way.

The other plan is to run it off of an Chinese Mega2560 clone ($10 from ebay, just the atmega2560 uC is more than that everywhere I’ve looked) with the appropriate shield (another $7ish) .

So could I get some input on the pros and cons of each way of doing it? Or perhaps other solutions to the problem?

I run mine off a mega and shield. The main advantages for me were:

  1. It just works. No breadboarding, re-wiring, etc.
  2. It leaves lots of IO pins for other things, unlike running it off a UNO-ish thing.
  3. One side-benefit was that with the Mega, I got more ROM space. I was always a little concerned that 32K wasn’t going to be enough. As it was, it wasn’t, so I was glad to have the 256K of the Mega.

00101: My next thought is to run it off a shift register, similar to how the guy in the spritemods link did it. I'm concerned, though, how slow the display would be. I've read people having it take 4 seconds to clear the screen in similar configurations. All I need it to do is display some text data streams, static images, and run a couple sliders. So my needs aren't too demanding on it, so it might work this way.

The other plan is to run it off of an Chinese Mega2560 clone ($10 from ebay, just the atmega2560 uC is more than that everywhere I've looked) with the appropriate shield (another $7ish) .

So could I get some input on the pros and cons of each way of doing it? Or perhaps other solutions to the problem?

For 16 bit parallel you'll need 2 74HC595's daisy chained. Use the hardware SPI to drive the shift registers at full speed (8MHz) and direct port manipulation to drive the nCS, D/C and nWR lines.

SCLK would drive the clock input of the shift registers, MOSI to the data input, another pin (SS works OK) to the latch pins. You only need to feed the shift register when the values changes, which means that for repeated pixels you can just toggle the nWR line and get excellent speed writing TFT RAM. - This is a trick you cannot do on 8-bit parallel or SPI TFT modules BTW.

Realistically, how quickly would the display respond if driven by the 74HC595's? Like I said, I don't need it to be lightning fast, but I do need it to respond reasonably quickly.

Also another idea I had was to try to change the input on the SSD1289. I know that it doesn't bring them out to anything, but how difficult would it be to solder to them right on the driver IC? Though that does bring concerns that the UTFT library does not support the SSD1289 in serial mode. However, it does support it in 8-bit mode. That would significantly cut down pin usage which is another option.

Ha! Solder on the IC? I think you’ll find the SSD1289 is a CoG(*) with 1336 pads directly
bonded to tin-indium traces on the LCD back glass.

(*) Chip-on-Glass

And never mind. As I'm sure is evident, I'm very new to these sorts of things, and do not yet have the physical screen.

So shift registers are probably the way to go. Would there be an advantage to using a single 16 channel register vs 2 8 channel registers daisy chained?

Hi, It seems it is possible to use 8 bit interface from SSD1289 : http://www.raspberrypi.org/phpBB3/viewtopic.php?t=33679&p=398256 Has one of you already tried? I'm also facing the same problem choosing a screen, as I want to work on a Nano board and I nned SPI, I2C and One wire to work.

arduiiiino: Hi, It seems it is possible to use 8 bit interface from SSD1289 : http://www.raspberrypi.org/phpBB3/viewtopic.php?t=33679&p=398256 Has one of you already tried? I'm also facing the same problem choosing a screen, as I want to work on a Nano board and I nned SPI, I2C and One wire to work.

Forget that one on an ATMEGA - this is to slow. The Interface connectivity that's need to be used for that purposes is not available due the ATMEGA lacks in Memory or Memory-Bus availibility. Port-I/O connection and 8Bit handling works, but the result will not satisfied. The Font's consume much memory resorces and the MCU should do more jobs than just handle the display. The limit in MCU-Performance, Bus-Connectivity and Programm-memory for driving a TFT 320x240 or more, will disqualify the Atmel. 8Bit MCU to do this job successfully. Use just a different controller like an Atmel SAM3/ SAM4 (expensive Arduino.-DUE) or an STM32F4 Discovery Board (cheap and fast) that's gives you an unlimited access to the Memory, Bus and Performance (168Mhz). A 800x480 Pixel 16Bit TFT works floated and all you need is on-board - even the JTAG-USB Programmer/debugger. Juppeck

Hello every one, i need your help. I got a 3.2 TFT screen, and just want to display some text, not the touch. this is possible ? and how. kindly help me. Only following connections are needed? LEDA -> 3.3V VCC -> 5V RD -> 3.3V GND -> GND DB0->DB7 to pin D37->D30 DB8->DB15 to pin D22->D29 RS -> D38 WR -> D39 CS(pin6) -> D40 RSET-> D41

Hello everybody ! I'm a starter with arduino, and I have bought two TFT displays :

1: 2.4" with ILI9325 controller: http://www.ebay.com/itm/2-4-TFT-LCD-Module-Display-Touch-Panel-Screen-PCB-adapter-/400417743247?pt=LH_DefaultDomain_0&hash=item5d3ac1e18f 2: 3.2" with SSD1289 controller: http://www.ebay.com/itm/200908823757?_trksid=p2055120.m1438.l2649&ssPageName=STRK%3AMEBIDX%3AIT

I'm using an Arduino UNO R3 clone board,with Atmega328PU. The smaller 2.4" display work fine , but the 3.2" display doesn't work , not at all, just light backlight and that's all. I'm using tft shield, this one: http://www.ebay.com/itm/TFT-2-4-LCD-Touch-Shield-Expansion-Shield-for-Arduino-UNO-Mega2560-R3-/281150878452?pt=LH_DefaultDomain_0&hash=item4175e5f2f4 I have tried out UTFT library and many other libraries but the 3.2 TFT don't work with them , not at all! How can I use this 3.2" TFT with Arduino UNO R3? This can I use with UNO R3 board at all, or just with Mega2560 board? Thank you very much !

Hi everybody !

I think I have found the problem: I think the 3.2" TFT has got a 16 bits data interface. I tried out this article: http://www.sainsmart.com/zen/documents/20-011-918/3.2LCD+UNO.pdf and with the correct wiring it's working. My TFT Shield is working is 8 data bits. I have tried out the example code, contemplator.ino sketch and is working. But there some patterns in it which is working but there is flickering, vertical flickering white lines. I speak from experience this flickering is in connection with the drawing speed. When the drawing is slower there is less flickering. I think my 3.2" TFT coudn't work in 8 bit data modes if I'm not mistaken. But why there is flickering? Thank you very much yours answers!