Simple Problem with 1.8 TFT Module


i have a problem with wiring a 1.8 TFT module.

The constructor:

UTFT::UTFT(byte model, int RS, int WR,int CS, int RST, int SER)

The problem is that i dont know exatly what pins from the TFT module belongs to the constructor.
I want to use the yellow left pins from the TFT module.
(Its very interesting and funny, that for example the left pin number 4 is calles "DIN" and on the right side of the module it is calles "SDA". "CLK" on the left side is calles "SCK" on the right side.)

But let me come back to the problem. I am very shure, that the first three pins from the module belongs to the constructor like this.

CS -> CS
D/C -> RS ( because D/C left ist RS right)
DIN -> ??????
CLK -> ??????

It would be very nice if somebody could help me because i dont want to use a example programm with fixed Arduino pins. In addition i use a Arduino mega an there are no examples.


You have chosen to use UTFT. It has no concept of hardware SPI. You can select any pins that you like.

If you are using a sensible library like Adafruit_ST7735 or Bodmer's TFT_ST7735 then you would connect to the hardware SPI pins. And the library will function at about 10x the speed of UTFT.

You already have suitable wiring in your picture.
e.g. the pin called DIN / SDA goes to MOSI.
e.g. the pin called CLK / SCK goes to SCK

e.g. the pin called D/C / RS goes to any GPIO
e.g. the pin called CS goes to any GPIO. (I would choose SS)
e.g. the pin called RST/RESET goes to any GPIO

Yes, you can connect RST to the Arduino RESET pin but I do not recommend it.
The Adafruit library examples do not use a RESET pin in their constructor. However they accept an extra parameter that specifies a real GPIO pin.

Go to Bodmer's library. He has a Tutorial that shows you how to do everything.


Thanks for your answear David,

your "goes to" list helped me to

The problem ist, that every example and tutorial ist for the UNO and not for the mega2560.
I used both librarys, the "UTFT" and the "Adafruit_QDtech with Adafruit_GFX"

I checked both .cpp datas and compared the examples with the example scetches.
For example:

UTFT myGLCD(ITDB18SP,11,10,9,12,8);
That means for the UNO:

11 -> MOSI
10 -> SS
9 -> GPIO
12 -> MISO
8 -> GPIO

I am confused, that the SCK is not used because in the .cpp data

UTFT::UTFT(byte model, int RS, int WR,int CS, int RST, int SER)

I dont understand the opposition but try to testing the right layout.
I used the pin 51 MOSI and 52 SCK Pin on my mega but it will absolutely not work.
So i checked the other library (Adafruit). Here are the same problems.

The constructor is without any comment

Adafruit_QDTech::Adafruit_QDTech(uint8_t cs, uint8_t rs, uint8_t sid,
uint8_t sclk, uint8_t rst) : Adafruit_GFX(QDTech_TFTWIDTH, QDTech_TFTHEIGHT)

I checked the example programms but they all use the faster hardwareSPI variant with three pin constructor. That mustnt be a problem if the constructor would had any useful commentar. :frowning:

It was possible to get with both librarys a layout where the display makes dozends of colored rows, but that was not the example programm. I have two displays (both the same ).There must be any layout error i think. T could check every combination, that must be 5x4x3x2x1 = 120 possibilities.

I dont want to check this out but maybe before i spend another 10 hours with this crap i will do it. :wink:


I don't see the problem. From Adafruit_ST7735.h:

  Adafruit_ST7735(uint8_t CS, uint8_t RS, uint8_t SID, uint8_t SCLK, uint8_t RST);   //bit-bash
  Adafruit_ST7735(uint8_t CS, uint8_t RS, uint8_t RST);                // hardware SPI

From UTFT.h: (they name it for the parallel interface) they call D/C RS

  UTFT(byte model, int RS, int WR, int CS, int RST, int SER=0);     //generic parallel

From one of my sketches: (the constructor arguments are very different for a serial interface and D/C is in a different place)

//UTFT myGLCD(model   , MOSI, SCK,  CS, RST, D/C);  
UTFT myGLCD(ILI9341_S5P,  11,  13,  10,   8,   9);

Obviously you have chosen different pin numbers for your RST and D/C pins.
Since UTFT has no concept of hardware SPI, you have to specify all the pins.
The Adafruit constructor for hardware SPI does not specify MOSI, SCK pin because they are fixed in hardware.

Regarding Pin numbers, the UTFT website has some nice clear pin layout diagrams for Uno and Mega.
You must look up the pin numbers for hardware MOSI, SCK on a Mega.


Edit. I think that your blue module either has a ST7735S controller or a S6D02A1 controller. I have published a diagnostic sketch that will tell you which you have.
Bodmer has libraries for both controllers.
I doubt that Adafruit or others will work properly with the Samsung controller.

I have a display that looks physically identical to yours. Mine works with this library and a Mega when wired as follows:

Mega pin 44 to TFT RST via a 1K resistor
Mega pin 47 to TFT CS via a 1K resistor
Mega pin 48 to TFT D/C via a 1K resistor
Mega pin 51 to TFT DIN via a 1K resistor
Mega pin 52 to TFT CLK via a 1K resistor
Mega +5V to TFT VCC
Mega +5V to TFT BL

Inside the library folder there is a file called "User_Setup.h" that you will need to edit to set the display driver correctly. With my display the following work with the above pins:

#define TFT_CS  47  // Chip select control pin
#define TFT_DC  48  // Data Command control pin
#define TFT_RST 44  // Reset pin (could connect to Arduino RESET pin)

Note that Mega pins 51 and 52 are the hardware SPI pins (MOSI and SCK) and are automatically used by the library.

I've just tried UTFT with the pin connections wires as in post #4 above and this constructor works fine in the UTFT_Demo_160x128_Serial example sketch:

UTFT myGLCD(ITDB18SP,51,52,47,44,48);

Bear in mind that identical looking displays can have different drivers fitted in which case either the display will show nothing or colour bands when running a sketch. If that happens to you display after trying the settings in post #4 then we need to try a different library, for example this one which also includes a User_Setup file that will need to be configured for your pin connections.


thank you bodmer and David,

you both helped me to fix the problem!
I downloaded a Adafruit_ST7735 library (not from bodmers link, but from the same websit) like you both talking from and the example code shows that there is need no "chip-driver" argument. And it was working directly.
After it works with the ST7735 library from you i thought when it works with an ST7735 Object i have to tested it with the UTFT library and use as first parameter "ST7735" and not S6D02A1. It was working directly, too.

So the arduino mega pin problem was already fixed in my secon post, (SCLK 52, MOSI 51 for arduino mega) but even it was no working i thought the failure must be there. :wink:

can have different drivers

I use all the time at first parameter "S6D02A1". That seems to be correctly but was wrong for the scetch. I could have see it, because S6D02A1 was not getting "colored blue" in the scetch. ST7735 ist gettin "blue colored".

I take a look in the .cpp data and see that there is only one case -> ST7735.
I never see a case sensitivity like that before, but it seem that ST7735 is something like the mother of S6D02A1 and S6D02A1 cannot use as argument directly.

case ST7735:
 case HX8353:
 case S6D02A1:

@ bodmer i downloaded the ST7735 library from your link and see that there is another .cpp code as in my ST7735 library. So my library doesnt have the header data User_Setup.h. So there must exist two ore more ST7735 libraries! The constructor looks total different, too. Maybe i will testing your library.
Thanks for spending time in testing my code !

Thank you both again!

Here is a snipping from the constructor. Every driver have a own case.
Only SD602A1 :confused:

It looks like you have not understood how the case statements work.

case 0:
case 1:
case 2:
    // Code here runs for case 0, 1 or 2 but no others
case 3:
case 4:
    // Code here runs for case 3 or 4 but no others
    // Code here runs all other values

If you are still looking for a solution for this i may have it.

in the Adafruit library (atleast in the graphics test) there are two options for running the screen. the first option is faster, but caused my screen to remain white. by commenting out option 1 and un-commenting option 2 the screen ran fine.
NOTE: it still requires the 1Kohm resistors.

hope it helps