Go Down

Topic: 1.44 inch TFT 128x128 GLCD ILI9163 (Read 64018 times) previous topic - next topic

CrossRoads

"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?"
No, SPI is a set & forget transfer.  You write into a register, the hardware does the transfer by itself, it interrupts when done so the code knows the hardware is available for another transfer.  It takes 17 clocks to send out the 8 bits.
Designing & building electrical circuits for over 25 years.  Screw Shield for Mega/Due/Uno,  Bobuino with ATMega1284P, & other '328P & '1284P creations & offerings at  my website.

david_prentice

#46
Jan 17, 2016, 11:07 am Last Edit: Jan 17, 2016, 11:52 am by david_prentice
Regarding the "ST7735" RDDID command.

I have data sheets for "ST7735 (V2.1) ST7735R (V1.4) , ST7735S (V1.1)

Code: [Select]

ST7735  implies 5C 8x xx
ST7735R implies 5C 8x xx
ST7735S implies 7C 8x xx

ILI9163C states 54 80 66



I have always assumed that my displays were ST7735R.   However Vertical Scroll works on both my Red and Blue 128x160 displays.
Since only the ST7735S controller supports scrolling,   I conclude that is the device that is installed.
And my ID reads as 7C 89 F0

I only managed to get the ST7735S datasheet this morning by running Internet Explorer.   My Firefox would crash on the Crystalfontz site.

I suspect that you have another variant of the ST7735 but it seems very difficult to get information.

TFT data sheets are fairly complex.   It is not unknown for them to have typos and plain errors.


David.

Edit. The nice Crystalfontz site supplied me with ST7735R v1.4

gimpo

@ CrossRoads

than you for your clarifying answer.

@ David

I'm a little bit lost with all that numbers. Anyway, as I understand, the crucial command to get the chip identification is the command "RDDID (04h): Read Display ID". It returns 4 bytes but the first byte has to be ignored.
From above command your ID is 0x7C89F0, mine is 0x9101, so mine is completely different from your. From where you think that I have some kind of ST7735 too?

Just one note/consideration: if we have ST7735something then also the device driver by Adafruit (i.e. Adafruit_ST7735.h) should work. Did you take a try?
Arduino, what else?

david_prentice

I am sure that the Adafruit library will work with your display.

You just have to tell it 128x128.

Try it for yourself.

David.

gimpo

#49
Jan 17, 2016, 04:20 pm Last Edit: Jan 17, 2016, 04:26 pm by gimpo
I made same tests with the the same sketch but using Adafruit_ST7735.h.

Problems:

1) No proper init parameter available

The tft.initR(INITR_144GREENTAB) instruction doesn't work, one has to use 128x160 pixel black tab:

tft.initR(INITR_18BLACKTAB);

2) Screen shift

The screen is shifted down of 32 pixels, one has to use the instruction

tft.setRotation(2);

to place the origin in the upper-left corner

3) Wrong colors

Colors are wrong, a red line is drawn with blue color on the screen (!)

Apart problems above adafruit driver works, but I noticed immediately one big difference: drawing lines with adafruit libs is much more slow than with sumotoy libs. On the other hand, clearing the screen with Adafruit libs is faster than with sumotoy ones.

I ran the same graphical test: drawing lines from one corner to the opposite sides of the screen - repeated for all 4 corners. I modified it by erasing the clearScreen() instruction that was executed before starting drawing the lines from one corner.
Here the numbers (milliseconds):
test                           Adafruit libs  Sumotoy libs
4-corners lines73154465
20xfillScreen() loop    41828122


So sumotoy libs have amazing drawing performances but are double more slow when cleaning the screen!

p.s: I've checked the SPI settings used by Adafruit libs and they're set to max clock speed. No further improvement from that front.
Arduino, what else?

gimpo

From what above, my suggestion is to use sumotoy libs avoiding to use clearScreen() and/or fillScreen() instruction as much as you can.
Arduino, what else?

david_prentice

Please PM me with your email address.   

Since you are using fixed GPIO pins,  my library should work for you.

Regarding speed.   It should not be a problem.

David.

gimpo

Arduino, what else?

gimpo

#53
Jan 18, 2016, 07:25 pm Last Edit: Jan 18, 2016, 07:30 pm by gimpo
Still problems with the setRotation() instruction. It rotates but, again, the "32 pixel shift-down" appears again with parameter 2 or 3. So I cannot use the display in upside-down configuration as I need.
Before you ask, I have also tried all possible combinations of #define statements into the sumotoy's libs, no way. It can only go further down, it never raise up to the top (even with negative values of the __OFFSET variable and even uncommenting __OFFSET usage in the TFT_ILI9163C::setRotation() function).

I hope that photos below will help somebody to identify and run away from "false" red tabs like mine.


Original sumotoy's red tab:


My "false" red tab:


BTW. Mine has also NO identification number or code printed anywhere on the side of the TFT.
Arduino, what else?

gimpo

Just to be more clear about the problem. I run just a basic sketch drawing a 128x128 triangle with the tip upwards.

Output with setLocation(0):


Output with setLocation(2):

Arduino, what else?

olikraus

Hi

The ILI9163 is indeed a little bit tricky regarding rotation. I remember that i had some trouble to make the rotation work correctly in ucglib. Nevertheless, if you really need rotation, maybe ucglib could be an option: https://github.com/olikraus/ucglib/wiki/reference#setrotate180

I never compared speed of ucglib with other libs, but ucglib includes some speed optimizations.

Oliver

gimpo

Hi Oliver,

I didn't heard anything about ucglib until now. I will take a try, thanks!
Arduino, what else?

gimpo

#57
Jan 20, 2016, 08:10 pm Last Edit: Jan 20, 2016, 08:13 pm by gimpo
In the meanwhile... I have received a "true" red tab TFT and it works nice with sumotoy's lib. Zero problem by using #define __144_RED_PCB__
The setRotation() function does its work now!


By visually inspecting the "true" red tab with the "false" I have noticed several differences:

- the PCB color is really red (the previous was close to orange)
- the PCB is 2mm higher
- the plastic white frame around the display area is thicker than the previous one



Arduino, what else?

gimpo

#58
Jan 20, 2016, 08:17 pm Last Edit: Jan 20, 2016, 08:18 pm by gimpo
p.s: in any case all sumotoy's primitives filling a pixel-area remains slower than with Adafruit libs (including the fillScreen() function). But it works, that matters to me.
Arduino, what else?

gimpo

Hi

The ILI9163 is indeed a little bit tricky regarding rotation. I remember that i had some trouble to make the rotation work correctly in ucglib. Nevertheless, if you really need rotation, maybe ucglib could be an option: https://github.com/olikraus/ucglib/wiki/reference#setrotate180

I never compared speed of ucglib with other libs, but ucglib includes some speed optimizations.
Hi again,
I tried some demos of your library and still the same problem with the "false" red tab: the screen is shifted down of 32 pixels  :(
With the new red tab I bought everything works fine (even the rotation of the screen). I have used the following constructor:

Ucglib_ILI9163_18x128x128_SWSPI ucg(/*sclk=*/ 13, /*data=*/ 11, /*cd=*/ 9 , /*cs=*/ 10, /*reset=*/ 8);


Nice library, cool functions and very good documentation! Unfortunately it has the same problem as with sumotoy lib: when filling an area (or clearing the screen) the function are soooo slow...  :(
Arduino, what else?

Go Up