colours of st7735 TFT

I am using a ST7735 TFT with res of 160×228 in 16bit colour mode.

When I display images they are tinted blue, this is very noticeable when I display white as it will display a shad of blue instead.

I assume that it is the gamma that I need to adjust?? there is too much gain on the blue channel??

I am not quite sure how gamma adjustment works. Can anyone explain it to me??

which core
which board
which lib

I make my own library.

It is about understanding how to program the ST7735 not about the board or core.

I assume it is about setting these registers

GMCTRP1 (E0h): Gamma (‘+’polarity) Correction Characteristics Setting
GMCTRN1 (E1h): Gamma ‘-’polarity Correction Characteristics Setting

[flyboy74 – Wed Aug 22, 2018 9:45 pm] –
I make my own library.

It is about understanding how to program the ST7735 not about the board or core.

I assume it is about setting these registers

GMCTRP1 (E0h): Gamma (‘+’polarity) Correction Characteristics Setting
GMCTRN1 (E1h): Gamma ‘-’polarity Correction Characteristics Setting

You are writing your own graphic library and you are asking the forum to help you understand how to set the ST7735 gamma? Seriously, dude?

I will suggest pulling other ST7735 compatible libraries and investigate how other programmers attack the issue. A quick Google search should get you started.

One result is a PDF that looks promising.

Ray

Did you also test with other displays? There’s the possibility it’s a hw fault inthat item..

Looking through the Adafruit lib, I found this:
https://github.com/adafruit/Adafruit-ST … 0d86c5ad12

Which provides the following info about where in the data sheet the init sequence is defined:
Info on pages 148-151 on this ST7735 datasheet: ftp://imall.iteadstudio.com/IM120419001 … ST7735.pdf

More searching found a Python implementation that is better documented and does not make reference to “magic dust” …
if width not in [128, 160] or height != 128:
raise luma.core.error.DeviceDisplayModeError(
"Unsupported display mode: {0} x {1}".format(width, height))

# RGB or BGR order
order = 0x08 if bgr else 0x00

self.command(0x01) # reset
self.command(0x11) # sleep out & booster on
self.command(0xB1, 0x01, 0x2C, 0x2D) # frame rate control: normal mode
self.command(0xB2, 0x01, 0x2C, 0x2D) # frame rate control: idle mode
self.command(0xB3, 0x01, 0x2C, 0x2D, # frame rate control: partial mode dot inversion mode
0x01, 0x2C, 0x2D) # frame rate control: line inversion mode
self.command(0xB4, 0x07) # display inversion: none
self.command(0xC0, 0xA2, 0x02, 0x84) # power control 1: -4.6V auto mode
self.command(0xC1, 0xC5) # power control 2: VGH
self.command(0xC2, 0x0A, 0x00) # power control 3: OpAmp current small, boost freq
self.command(0xC3, 0x8A, 0x2A) # power control 4: BCLK/2, Opamp current small & Medium low
self.command(0xC4, 0x8A, 0xEE) # power control 5: partial mode/full-color
self.command(0xC5, 0x0E) # VCOM Control 1
self.command(0x36, 0x60 | order) # memory data access control
self.command(0x20) # display inversion off
self.command(0x3A, 0x06) # interface pixel format
self.command(0x13) # partial off (normal)
self.command(0xE0, # gamma adjustment (+ polarity)
0x0F, 0x1A, 0x0F, 0x18, 0x2F, 0x28, 0x20, 0x22,
0x1F, 0x1B, 0x23, 0x37, 0x00, 0x07, 0x02, 0x10)
self.command(0xE1, # gamma adjustment (- polarity)
0x0F, 0x1B, 0x0F, 0x17, 0x33, 0x2C, 0x29, 0x2E,
0x30, 0x30, 0x39, 0x3F, 0x00, 0x07, 0x03, 0x10)

self.clear()
self.show()

The ST7735S datasheet describes the GAMMA registers and how the parameters work.

There are dozens of 132×162 TFT controllers. Are you sure that you have a Sitronics chip?
Many manufacturers return similar ID values. So simply reading the ID is not sufficient.
You need to do some detective work e.g. compare behaviour of Manufacturer registers.

I suggest that you post a link to the actual display that you have bought.
And run the same code on a second display.

It is possible that you have a reject display. Either the TFT matrix or the Silicon in the controller.

David.

[edogaldo – Thu Aug 23, 2018 7:32 am] –
Did you also test with other displays? There’s the possibility it’s a hw fault inthat item..

This is my suspicion.

Changing the gamma settings won’t solve the problem anyway. The same settings are used for each of the colours. It won’t be possible to change it just for the blue.

It might be worth changing the pixel format to see if that has any effect (the display supports 12, 16 and 18 bit modes) but there’s no guarantee that will help.

Really stupid question that nobody thinks to ask: You have checked there isn’t a blue tinted film covering the display for protection during shipping haven’t you?

[dave j – Thu Aug 23, 2018 1:33 pm] –

[edogaldo – Thu Aug 23, 2018 7:32 am] –
Did you also test with other displays? There’s the possibility it’s a hw fault inthat item..

This is my suspicion.

Changing the gamma settings won’t solve the problem anyway. The same settings are used for each of the colours. It won’t be possible to change it just for the blue.

It might be worth changing the pixel format to see if that has any effect (the display supports 12, 16 and 18 bit modes) but there’s no guarantee that will help.

Really stupid question that nobody thinks to ask: You have checked there isn’t a blue tinted film covering the display for protection during shipping haven’t you?

Yes I have found my code doesn’t have the blue tint problem on other HW so it is looking like that the HW is as fault but I was hoping it would be possible to compensate in software for the blue tint.

I brought it cheap from aliexpress. I am thinking anytime a manufacture gets a batch of product that is maybe a little out of QA instead of throwing it out they flog it off though aliexpress sellers.

Ok, so it seems that red and green pixels are not bright enough..
You should check how to lower the blue brightness in order to balance the defect..

[edogaldo – Thu Aug 23, 2018 11:04 pm] –
Ok, so it seems that red and green pixels are not bright enough..
You should check how to lower the blue brightness in order to balance the defect..

Yes this is what I wanted to do but have been unable to work out if it is possible to adjust the gain on individual channels.

[flyboy74 – Fri Aug 24, 2018 11:58 am] –

[edogaldo – Thu Aug 23, 2018 11:04 pm] –
Ok, so it seems that red and green pixels are not bright enough..
You should check how to lower the blue brightness in order to balance the defect..

Yes this is what I wanted to do but have been unable to work out if it is possible to adjust the gain on individual channels.

I don’t think it’s possible to get the TFT to adjust it for individual channels.

This paper gives a good description of how TFT controllers work internally and will give clues as to what is happening with your display. To me it looks like the problem is either in writing the green/red bits to the memory or transferring them from the memory to the D/A converters (see figure 7a).

This leaves fixing it in code.

The first thing to do is find out which bits of the red and green channels aren’t getting to the display. I’d suggest writing a program to draw grey bars across the screen with one bit in turn off and all the others on. e.g. for a display with 4 bits per colour you’d use 0x7, 0xb, 0xd and 0xe. If a bar is not grey, the corresponding bit will not be working. Note, it might not be the same bit for the red and green channels.

Once you’ve identified which bits are affected you have two choices:

1. If enough of the top most significant bits work on all the channels, say the top four, for you to be able to live with the reduced colour depth you could just mask off all the bits below that. Given this display supports a 12 bit per pixel mode, if you can live with 4 bits per channel or less you could switch to that mode and reduce the amount of data you need to send to the display.
2. If too high a bit isn’t working for you to live with the reduced colour depth you’ll have to write code to avoid using it.

   Lets say the second most significant bit of a 5 bit (so range from 0x00 to 0x1f) channel isn’t working. Anything with the 0x08 bit set will give the wrong colour. But, 0x07 is very close to 0x08 so why not reduce everything below the top bit by 1. Some code will make that clearer:
   newColour = (oldColour & 0x10 ) + (oldColour & 0x0f) - 1;


Thanks a lot for the link dave j I will spent some time to read it closely to better understand my problem. At just the breif glance over it could be a possible be a voltage drive generator problem too and there is a number of registers that can be set to adjust this.

[flyboy74 – Sat Aug 25, 2018 6:42 am] –
Thanks a lot for the link dave j I will spent some time to read it closely to better understand my problem. At just the breif glance over it could be a possible be a voltage drive generator problem too and there is a number of registers that can be set to adjust this.

The voltage drive generator appears to apply to all channels equally so I’m doubtful about that helping.

BTW ignore my second suggestion for a fix – I’ve realised it won’t do what I thought it would. You could do something similar to get an extra effective bit. Lets say the 3rd MSB of a 5 bit channel isn’t working. You could doif (value & 0x4)
value |= 0x3;


[dave j – Sat Aug 25, 2018 10:21 am] –

[flyboy74 – Sat Aug 25, 2018 6:42 am] –
Thanks a lot for the link dave j I will spent some time to read it closely to better understand my problem. At just the breif glance over it could be a possible be a voltage drive generator problem too and there is a number of registers that can be set to adjust this.

The voltage drive generator appears to apply to all channels equally so I’m doubtful about that helping.

BTW ignore my second suggestion for a fix – I’ve realised it won’t do what I thought it would. You could do something similar to get an extra effective bit. Lets say the 3rd MSB of a 5 bit channel isn’t working. You could doif (value & 0x4)
value |= 0x3;