1.44 inch TFT 128x128 GLCD ILI9163

Well, instead of making untested assertions, I connected a red 1.44" module: pin#1: VCC = 5V pin#2: GND = 0V pin#3: CS = 5V via a 3k0 resistor (or 0R, 6k0)

The DMM showed 220uA current via the 3k0 resistor. And 300uA via a 0R resistor, 150uA via 6k0.

So I conclude that the module has some onboard series resistance and it is conducting through the substrate diode.

300uA is going to be harmless to the chip, but it will be backfeeding the LDO regulator. i.e. the chip supply voltage will be slightly above 3.3V.

Personally, I always use 3.3V logic. An input pin will be very high impedance. i.e. you would not expect any measurable current from the AVR logic output pins. And consequently no backfeed of voltage past the LDO.

No, I can't be bothered to risk running my 1.44" with 5V logic.

I know for a fact that the 2.2" 240x320 red modules do NOT work with 5V logic. I did the same test on a 2.2". And got similar currents.

So I suspect that you will not harm the chip with these modest currents. But the controller may not work. For the sake of a $0.05 you might just as well play safe. And buy some resistors. Or run at 3.3V in the first place.

Regarding Ebay listings. The vendors will say anything to make you buy their goods.

Edit. My 1.44" looks just like the one in your link.

David.

Well, I've just ordered a couple of Pro Mini at 3.3Volts.

In any case 300mA it's a lot of current, seems that the IC cannot work with 5V levels, it is to high. Why they soldered that voltage regulator on the board? Seems useless... Or it is just for powering purposes (not for the logic lines)?

The voltage regulator ensures that the chip is powered by a known voltage.

The substrate diodes are supposed to be a protection measure. Not something that should be used as a matter of course.

I suspect that the traditional 5V 8051 will be reasonably safe. It can't source a high logic level. It can only sink a low logic level.

If you look at Ebay photos, they are often with 8051-style boards.

Where did you get 300mA? Something must be seriously broken. e.g. a blown chip.

David.

david_prentice:
Where did you get 300mA? Something must be seriously broken. e.g. a blown chip.
David.

Ooops! My error: I’ve read milli in place of micro.

Hello again. I bought the "red tab" 1.44" TFT and plugged into a new Arduino Pro mini @ 3.3V as suggested above:

sck =pin 13 reset = pin 12 sda = pin 11 cs = pin 10 A0 = pin 9 GND = GND VCC = VCC = 3.3V LED = 3.3v

Unfortunately it doesn't work properly :(

I mean... when I run the test program attached above the origin of the screen is translated down of (circa) 30-35 pixels. The demo test runs well but I see just 3/4 of it on the screen. The zone of the screen above the false origin is not black, it's filled with pixels painted randomly. I suspect that there is some memory alignment problem...

I've just tested a second new TFT but the problem remains. Any clue? (I'm hitting my head to the wall...)

p.s: I didn't shorted the Jumper J1 to bypass the voltage regulator, but I don't think that the problem is cause of that.

I have installed the latest library versions but nothing has changed, problem is still there:

Adafruit_GFX library = version 1.1.3 TFT_ILI9163C library = version 0.9 Arduino IDE = version 1.6.5

I've also tried to use several #define directives as indicated in the sumotoy GitHub site but the dose not affect the results (I suspect that instruction are referring older versions of the library).

The screen seems always shifted down of around 32 pixels....

It is a feature of the cheap red displays. I think that a black display does not have the problem.

It is easy enough to cope with this. You simply add 32 to Y coordinate. Or run it in PORTRAIT mode rather than PORTRAIT_REV mode.

If you are using 3.3V, the TFT_ILI9163C works fine. I have my own library that works fine too.

David.

Nice to hear you again David.

Unfortunately modifying the instruction setCursor(0,0) with x=0 and y=-10 or -16 or -32 doesn’t work. What is in the upper zone is simply not printed at all (see attached photo - there you can see a fragment of the “Hello World!” string in white).

Also using the function setRotation(0…3) doesn’t work. The text does not rotate at all (on the Adafruit ST7735R that function was working indeed).

With graphic primitive (fillRect, fillTriangle, etc.) setRotation works, but text doesn't rotate. In any case the upper area is never painted, neither with text nor with graphic primitives.

I've no idea of what it's going on. I've opened an issue on the sumotoy GitHub page.

SOLVED!

My red tab is just... a black tab with different color! :astonished:

After looking with attention at the image to the red tab used by sumotoy I've discovered some subtle differences about the soldered tracks on the rear side. So doubt arises in my mind.

So, for Arduino Pro Mini 3.3V/8Mhz + "false" red tab 1.44" 128x128 ILI9163C TFT one has:

1) locate the TFT_ILI9163C-master directory in the IDE libraries

2) navigate and open the file

/TFT_ILI9163C-master/_settings/TFT_ILI9163C_settings.h

3) comment the line

define 144_RED_PCB//128x128

4) uncomment the line

// #define 144_BLACK_PCB//128x128

5) restart the Arduino IDE

By the way, since pin 12 on the Pro Mini is part of the four magic SPI pins it's better to not use it for the reset signal. So, here below my new wiring:

| Arduino Pro Mini ** | **false Red Tab TFT | | - | - | | pin 13 (SCK) | SCK | | pin 11 (MOSI) | SDA | | pin 10 (SS) | CS | | pin 9 | AO | | pin 8 | RESET | | VCC | VCC | | GND | GND | | VCC | LED |

Obviously, the code at the beginning of the test.ino sketch (posted at the beginning of this thread) should contains the modified instruction

define __RST 8 // was pin 12

Well, since Pro Mini 3.3V runs "only" at 8 Mhz it would be not a bad idea to speed up the SPI communication using the clock divider register. But that's another story.

Updates about Arduino Pro Mini 3.3V/8Mhz


Seems that there is no way to speed up drawing performances further. Sumotoy libs are using SPI settings at their best.

Since arduino is an AVR device and new libs provide SPI transactions then the line 309 of the TFT_ILI9163.cpp is executed and used around the program: . . . ILI9163C_SPI = SPISettings(8000000, MSBFIRST, SPI_MODE0); . . .

In fact, 8,000,000 is really the max speed that you can use on an 8Mhz processor (even if that value is just the max that can be used by SPI communications, not the actual).

I tried to substitute different values while running a stupid graphical test (the one drawing lines from the four corners of the screen). Here below the results:

| parameter | execution time (ms) | | - | - | | 500,000 | 12042 | | 1,000,000 | 8639 | | 2,000,000 | 6940 | | 3,000,000 | 6940 | | 4,000,000 | 6089 | | 5,000,000 | 6089 | | 6,000,000 | 6089 | | 7,000,000 | 6089 | | 8,000,000 | 6089 |

(Quite strange that third and fourth values give the same result...)

So seems that there is not so much to do to increase drawing speed. On the Pro mini performance are not so poor, are simply honest performance. But when I see test videos with Tensy I get envy... :astonished:

Any other idea is welcome.

(sumotoy is preparing version 1.0 of his libs, maybe there will be some further optimization, I don't know...)

Go on. The 128x128 screen is so small that you never notice the speed.

I am fascinated by your red/black discoveries.

Since you are running at 3.3V without any level-shifting, the display should work 100%.

Please could you run this sketch and copy-paste the result from the Serial Terminal.

// see if 4-line mode can read anything

#define TFT_MOSI 11
#define TFT_SCK  13
#define TFT_SS   10
#define TFT_DC  (9)     //DC=7 for HX8347
#define TFT_RESET (8)   //Backlight on HX8347
char *chip = "controller";

#if defined(SPDR)
// use SPI mode #0
uint8_t spi(uint8_t c)
{
    SPDR = c;
    while ((SPSR & 0x80) == 0) ;
    return SPDR;
}
#endif

uint32_t readwrite8(uint8_t cmd, uint8_t bits, uint8_t dummy)
{
    uint32_t ret = 0;
    uint8_t val = cmd;
    int cnt = 8;
    digitalWrite(TFT_SS, LOW);
#if 0
    SPSR = (0 << SPI2X);
    SPCR = (1 << SPE) | (1 << MSTR) | (1 << SPR0); //1MHz
    digitalWrite(TFT_DC, LOW);
    pinMode(TFT_MOSI, OUTPUT);
    spi(cmd);
    if (bits) {
        digitalWrite(TFT_DC, HIGH);
        pinMode(TFT_MOSI, INPUT);
        while (bits) {
            ret <<= 8;
            ret |= spi(0x00);
            bits -= 8;
        }
        ret >>= dummy;
    }
#elif 0
    digitalWrite(TFT_DC, LOW);
    pinMode(TFT_MOSI, OUTPUT);
    for (uint8_t i = 0; i < 8; i++) {   //send command
        if (val & 0x80) PORTB |= (1 << 3);
        else PORTB &= ~(1 << 3);
        PORTB |= (1 << 5);
        PORTB &= ~(1 << 5);
        val <<= 1;
    }
    if (bits == 0) {
        digitalWrite(TFT_SS, HIGH);
        return 0;
    }
    pinMode(TFT_MOSI, INPUT_PULLUP);
    digitalWrite(TFT_DC, HIGH);
    for (uint8_t i = 0; i < dummy; i++) {  //any dummy clocks
        PORTB |= (1 << 5);
        PORTB &= ~(1 << 5);
    }
    while (bits) {
        for (uint8_t i = 8; i-- > 0; ) {  // read results
            val <<= 1;
            if (PINB & (1 << 3)) val |= 1;;
            PORTB |= (1 << 5);
            PORTB &= ~(1 << 5);
        }
        bits -= 8;
        ret <<= 8;
        ret |= val;
    }
#else
    digitalWrite(TFT_DC, LOW);
    pinMode(TFT_MOSI, OUTPUT);
    for (int i = 0; i < 8; i++) {   //send command
        digitalWrite(TFT_MOSI, (val & 0x80) != 0);
        digitalWrite(TFT_SCK, HIGH);
        digitalWrite(TFT_SCK, LOW);
        val <<= 1;
    }
    if (bits == 0) {
        digitalWrite(TFT_SS, HIGH);
        return 0;
    }
    pinMode(TFT_MOSI, INPUT_PULLUP);
    digitalWrite(TFT_DC, HIGH);
    for (int i = 0; i < dummy; i++) {  //any dummy clocks
        digitalWrite(TFT_SCK, HIGH);
        digitalWrite(TFT_SCK, LOW);
    }
    for (int i = 0; i < bits; i++) {  // read results
        ret <<= 1;
        if (digitalRead(TFT_MOSI)) ret |= 1;;
        digitalWrite(TFT_SCK, HIGH);
        digitalWrite(TFT_SCK, LOW);
    }
#endif
    digitalWrite(TFT_SS, HIGH);
    return ret;
}

void showreg(uint8_t reg, uint8_t bits, uint8_t dummy)
{
    uint32_t val;
    val = readwrite8(reg, bits, dummy);

    Serial.print(chip);
    Serial.print(" reg(0x");
    if (reg < 0x10) Serial.print("0");
    Serial.print(reg , HEX);
    Serial.print(") = 0x");
    if (val < 0x10) Serial.print("0");
    Serial.println(val, HEX);

}

void setup() {
    // put your setup code here, to run once:
    uint32_t ID = 0;
    Serial.begin(9600);
    Serial.println("Bi-directional Read registers");
    digitalWrite(TFT_SS, HIGH);
    //    digitalWrite(TFT_SCK, HIGH);
    pinMode(TFT_SS, OUTPUT);
    pinMode(TFT_SCK, OUTPUT);
    pinMode(TFT_MOSI, OUTPUT);
    pinMode(MISO, INPUT);
    pinMode(TFT_DC, OUTPUT);
    pinMode(TFT_RESET, OUTPUT);
    digitalWrite(TFT_RESET, HIGH);
    digitalWrite(TFT_RESET, LOW);   //Hardware Reset
    delay(50);
    digitalWrite(TFT_RESET, HIGH);
    showreg(0x01, 0, 0);            //Software Reset
    delay(100);
    ID = readwrite8(0x04, 24, 1);
    if (ID == 0x7C89F0uL) chip = "ST7735R";
    if (ID == 0x548066uL) chip = "ILI9163C";
    ID &= 0xFF0000;
    if (ID == 0x5C0000) chip = "ST7735";
    showreg(0x04, 24, 1);  //RDDID
    showreg(0x09, 32, 1);  //RDDSTATUS
    showreg(0x0A, 8, 0);
    showreg(0x0B, 8, 0);   //RDDMADCTL
    showreg(0x0C, 8, 0);   //RDDCOLMOD
    showreg(0x0D, 8, 0);
    showreg(0x0E, 8, 0);
    showreg(0x0F, 8, 0);
    showreg(0x2E, 24, 8);  //readGRAM
    showreg(0xDA, 8, 0);   //RDID1
    showreg(0xDB, 8, 0);   //RDID2
    showreg(0xDC, 8, 0);   //RDID3
}

void loop() {
    // put your main code here, to run repeatedly:

}

My red display shows an ID of 0x548066

Bi-directional Read registers
controller reg(0x01) = 0x00
ILI9163C reg(0x04) = 0x548066
ILI9163C reg(0x09) = 0x610000
ILI9163C reg(0x0A) = 0x08
ILI9163C reg(0x0B) = 0x00
ILI9163C reg(0x0C) = 0x06
ILI9163C reg(0x0D) = 0x00
ILI9163C reg(0x0E) = 0x00
ILI9163C reg(0x0F) = 0x00
ILI9163C reg(0x2E) = 0x00
ILI9163C reg(0xDA) = 0x54
ILI9163C reg(0xDB) = 0x80
ILI9163C reg(0xDC) = 0x66

Your controller might have a different ID. Otherwise there is no way to tell whether the display has been configured for 128x132 or 128x128.

David.

I believe SPI clock of 4 MHz is the fastest you can get with 8 MHz system clock. See Table 19-5. Relationship Between SCK and the Oscillator Frequency of the '328P datasheet for example. The 7 SCK clock rates are Fosc (system clock) divided by 2,4,8,16,32,64 and 128.

Yes, 4MHz is maximum. With care you can run the SPI with "minimal" gaps.

All the same, even at 4MHz, 128x128 is not going to take very long to draw.

David.

david_prentice: Please could you run this sketch and copy-paste the result from the Serial Terminal.

Here the result:

controller reg(0x01) = 0x00
controller reg(0x04) = 0x9101
controller reg(0x09) = 0x610000
controller reg(0x0A) = 0x08
controller reg(0x0B) = 0x00
controller reg(0x0C) = 0x06
controller reg(0x0D) = 0x00
controller reg(0x0E) = 0x00
controller reg(0x0F) = 0x00
controller reg(0x2E) = 0xFFFFFF
controller reg(0xDA) = 0x00
controller reg(0xDB) = 0x91
controller reg(0xDC) = 0x01

What is your conclusion?

My conclusion is that you have a different ID. So my library can run "native" when it finds your ID.

If it finds my ID, it makes the appropriate 32 pixel shift.

Where did you get your "good" red display? I thought that it was only the black pcb that behaved properly. They are very sweet little displays. Admittedly, the 128x160 ST7735 red displays are just a bit more useful. They have an SD socket and a screen that can provide readable text.

David.

david_prentice: All the same, even at 4MHz, 128x128 is not going to take very long to draw.

Yes, performances are honest. I'm building a little gauge for motorcycle, it gets the input from various sensors. Now I observe just a little flickering when redrawing some "big" numbers on the display, but results are acceptable anyway (I have yet optimized my drawing routine).

Sumotoy claims that for his version 1.0 of TFT_ILI9163C libs he will [u]abandon[/u] Adrafruit_GFX libs. He is writing his own graphical libs (there are yet some pre-releases on GitHub). I think/hope that there will be some little improvement about performance 'cause of this. I will see...

david_prentice: My conclusion is that you have a different ID. So my library can run "native" when it finds your ID.

So my red tab is not simply a black tab painted with another color. It's a new animal in the zoo! :)

david_prentice: If it finds my ID, it makes the appropriate 32 pixel shift.

Since you have a "genuine" black tab (if I remember right) the __OFFSET variable in that xyzwhatever.h file is set to 0. Do you apply the shift on your own? Maybe are you using an old version of sumotoy's libs (less than 0.9)?

david_prentice: Where did you get your "good" red display? I thought that it was only the black pcb that behaved properly.

I saw many red tabs at cheap prices offered on ebay. But I was impatient so I've ordered one from this german vendor (yes, the price is too high). No idea from where the vendor is getting that TFTs.

CrossRoads: I believe SPI clock of 4 MHz is the fastest you can get with 8 MHz system clock. See Table 19-5. Relationship Between SCK and the Oscillator Frequency of the '328P datasheet for example. The 7 SCK clock rates are Fosc (system clock) divided by 2,4,8,16,32,64 and 128.

Just a question/curiosity: increasing the SPI speed has some kind of impact on the processor performances? I mean... it slows down the processor somehow?

What style of gauge do you want?

A bar graph is easy. A clockface gauge is a lot harder.

For a motorcycle, you want a steady display. You just need to display a running average. Whether for RPM or for KPH.

I have no intention of abandoning the Adafruit graphics. I might draw the text in hardware for bigger displays. As I said, 128x128 is very quick to update.

David.