Summary

This article will take you through a high level overview of all of the parts of a TFT LCD display.  The vast majority of what I have read on the internet makes this whole issue massively complex.  I’m quite sure that this complexity problem is a real reflection of the serious design and manufacturing complexity in these displays and drivers.  That being said, to get a conceptual understanding is much simpler, and is the point of this article.

A significant amount of my learning about this subject came from a 195 page powerpoint presentation by Dr. Fang-Hsing Wang entitled “Flat Panel Display : Principle and Driving Circuit Design“.  He has graciously allowed me to reproduce a few of his images.  This dude knows way way more about these circuits than I do and I would encourage you to read his work.

This article has the following subsections:

1. TFT Pixel
2. TFT Pixel Schematic
3. TFT Panels (Also known as TFT Glass)
4. TFT Gate Drivers
5. TFT Source Drivers
6. Gamma
7. Multiplexing Gate and Source Drivers

TFT Pixel

The fundamental element in a TFT display is the liquid crystal.  These elements have the property that the crystals will align from horizontal (which blocks the light) to vertical (which lets most of the light through) based on the electric field applied to them.  Basically, you shine light through the liquid crystal, which blocks some or all of the light, the remainder of the white light then goes through a color filter to make red, green, or blue. It works like this:

1. You use an array of LEDs to shine white light from the back of the screen towards the front (your eyes) 
2. Into a diffuser (to spread out the light and make it even)
3. You control the orientation of the crystals using a voltage to apply an electric field to the crystals
4. The white light from the back (often called the backlight) will shine through the liquid crystal elements.  The amount of light coming out will depend on the orientation of the crystals.
5. The white light coming out of the crystal will then go into a red, green or blue color filter making it red, green or blue (RGB)
6. The light from three RGB filters will combine in your eye into a color based on the amount of red, green and blue (purple in the case below)

This architecture means that every pixel in the display will require a red, green and blue element.  And, you will need to control the voltage on all of the elements (which will be quite a lot on a screen of any size)

Here is a nice cross section that I found on Innolux’s website.

Pixel Schematic

What does the schematic for one element in a pixel look like?  And where is the T(transistor) in the TFT?  The three letter acronym TFT stands for a thin film transistor that is physically on the top of the LCD matrix right next to each liquid crystal element.  Here is a schematic model for one element in the array.  C-LC represents the capacitance of the liquid crystal.  CS is a storage capacitor that is used to hold the electric field across the liquid crystal when the transistor is OFF.   To apply a voltage across the LC you just turn on the gate and apply the correct voltage to the column commonly known as the source.

You should notice that the “back” terminal of the two capacitors is called “VCOM” and is physically on the other side of the liquid crystal matrix from the TFT.  All of the liquid crystal backsides in the display are connected to the same VCOM.  A bit of painfulness in this system is that the CS capacitor leaks, which means that the LCD changes state which means that each pixel must be updated, properly called refreshed, on a regular basis.

TFT Panel

We know that each pixel has three three thin film transistors, three capacitors, three color filters (red, green and blue) and that we need to control the voltage on the source/drain of each transistor in order to cause the right amount of light to come through the liquid crystal.  How do we do that?  The first step is to arrange all of the pixels in a matrix.  Each row of matrix has all of the gates connected together.  And each column of the matrix has all of the sources tied together.  In order to address a specific pixel RGB element, you turn on the correct row and then apply a voltage to the correct column at the right time.

If you have been thinking about this system you might have done a little bit of math and figured out that you are going to need an absolute boatload of source and gate driver signals.  And you would be right!  For example, a 4.3″ screen with 480×272 will require 480x272x3 elements which are probably organized into 480 rows by 816 columns.  This would require a chip with at least 480+816=1296 pins, that is a lot.  It turns out that for small screens <=3.5″ there are chips with enough pins to do the job.  But, for larger screens, it requires multiple chips to do the job.  The “…” in the picture above shows the driver chips being cascaded.  The next thing to know is that “TFT Glass” usually has the driver chip(s) embedded into the screen at the edge (you can see that in the picture from Innolux above).

TFT Gate Drivers

You must put a quite high voltage source >20v and drain <-10V across the liquid crystal at the right time to get it to do its thing.  In order to pass that source voltage, the gate must be turned on at the right time to the right voltage, this is the purpose of the Gate Driver IC.  The gate driver is conceptually simple and Dr. Wang drew a nice picture on page 7 of his presentation.  You can see that it is basically a shift register, with one element per gate.  You shift in a “1” and then clock it through the entire shift register which will have the effect of applying a 1 to each gate.

However, a 3.3v logic 1 is not anywhere high enough to drive the gate so that it can pass the much higher source voltage.  So, you need to level shifter and a buffer to get the “right” voltage.   On page 15, Dr. Wang made a nice picture of this circuit as well.

It turns out that this picture is conceptually correct, but the exact implementation has “a lot going on”.  You can read about the next layer of circuit design in his presentation on pages 15-35.

TFT Source Drivers

In its most basic form, the TFT source driver is responsible for taking an 8-bit digital input value representing the value of an individual LCD element and turning it into a voltage, the driving the voltage.  Like this:

You could conceptually have one DAC per column in the panel.  But this would have at least two problems

1. The DACs are big circuits and this would make for giant source driver chips
2. You would need to “save” all of the digital values for an entire row so that when you turned on the row, you could turn on all of the DACs on at the same time.

You could conceptually also have one DAC for all of the columns, but this would have a bunch of problems including:

1. The DAC would have to be strong enough to drive all of the columns
2. You would need 3x the number of row drivers to effectively de-mux the column
3. You would need 1 pin on the source driver per column in the panel (for an 800×600 lcd that would be 600×3 = 1800 pins)

In reality there is some compromise of chip size, number of pins and time that is made by multiplexing pins, columns and rows.  For example, many of the small screens appear to have 1 column driver for all of the reds, 1 driver for the blues and one for greens. 

What appears to happen in real life on bigger screens is some combination of column and row multiplexing.  In one display that I found there were 2x the number of rows which allows the columns to be multiplexed 2-1.  The display is 1024×600.  That requires 1024*3 RGBs in the column = 1536 pins.  This means that you need to double the number of gate drivers, resulting in 1200 pins in the row direction.  Here is a picture from their datasheet.

Gamma Correction

The last issue that I will address in TFT LCD drivers is called Gamma Correction or more simply Gamma.  Gamma is an intensity adjustment factor.  For any given digital intensity input, you will need a non-linear translation to a voltage output on the source.  For example a doubling of digital input (so that a pixel appears twice as bright) you will not double but instead will have some non-linear translation of the output voltage.

There appear to be a bunch of reason why you need Gamma Correction including at least:

1. Your eye perceives light intensity in a non-linear way
2. The LCD panel responds differently based on the input
3. The intensity variance is dependent on the color

The good news is that this gamma correction is built into the display drivers.  From my reading, this is sometimes done with digital processing, and sometimes done with an analog circuit.  But in general, it appears to be tuned and programmed into the driver by the panel vendor for these smaller display.

In the next article I will write about TFT Controllers.

Embedded Graphics Index

Summary

I bought four MCU Friend 3.5″ TFT shields.  And, unfortunately, they have spiraled me into a deep, dark place trying to figure out how to use them.  The the documentation consists of a sticker on the antistatic bag, a picture of the shield with a list of 5 different possible LCD drivers, a pinout, and a block of code that supposedly represents the startup code.  The unfortunate part is that none of these have been exactly right – they all have errors.  This article is a description of the journey to figuring out how to use them.

This article has the following parts:

1. MCU Friend 3.5″ Documentation
2. MCU Friend 3.5″ Shields
3. Using the MCUFRIEND_kbv Library
4. Identify the LCD Driver with Register Reads
5. A PSoC Program To Identify LCD Controllers
6. Using the MCUFriend_kbv Startup Code
7. Use the Web Startup
8. Conclusion

MCU Friend 3.5″ Documentation

Here is a picture of the bag. (the QR code is a number “181024202132” which I thought might be a phone number but isn’t.  It also doesn’t match anything in google, so i’m not sure what it is.

This text on the website says:

Features:

•   5inch TFT LCD Module, Resolution 480×320, Controller ili9481 ili9468, ili9488 hx8357, or r61581.
•      Designed with a TF(Micro SD) card socket on the back of board so that you can conveniently insert a card.
•      Support touch screen function.
•      The test code is provided below.
•      This kit requires certain professional knowledge and ability, make sure you know how to use it, please. We cannot provide any technical assistance.

Specifications:

Controller: ili9481 ili9468, ili9488 hx8357, or r61581

Resolution: 480×320

Voltage: 5V/3.3V

Package Include: 1 x LCD Module

The website also has this code which they claim is the startup code.  It is interesting that

1. There are several lines are commented out
2. It implies that you have a  SPI interface
3. When you look at the commands some of them don’t exist in some of the controllers

write_SPI_commond(0xFF);
write_SPI_commond(0xFF);
delay_nms(5);
write_SPI_commond(0xFF);
write_SPI_commond(0xFF);
write_SPI_commond(0xFF);
write_SPI_commond(0xFF);
delay_nms(10);
write_SPI_commond(0xB0);
write_SPI_data(0x00);
write_SPI_commond(0xB3);
write_SPI_data(0x02);
write_SPI_data(0x00);
write_SPI_data(0x00);
write_SPI_data(0x10);
write_SPI_commond(0xB4);
write_SPI_data(0x11);//0X10
write_SPI_commond(0xC0);
write_SPI_data(0x13);
write_SPI_data(0x3B);//
write_SPI_data(0x00);
write_SPI_data(0x00);
write_SPI_data(0x00);
write_SPI_data(0x01);
write_SPI_data(0x00);//NW
write_SPI_data(0x43);
write_SPI_commond(0xC1);
write_SPI_data(0x08);
write_SPI_data(0x15);//CLOCK
write_SPI_data(0x08);
write_SPI_data(0x08);
write_SPI_commond(0xC4);
write_SPI_data(0x15);
write_SPI_data(0x03);
write_SPI_data(0x03);
write_SPI_data(0x01);
write_SPI_commond(0xC6);
write_SPI_data(0x02);
write_SPI_commond(0xC8);
write_SPI_data(0x0c);
write_SPI_data(0x05);
write_SPI_data(0x0A);//0X12
write_SPI_data(0x6B);//0x7D
write_SPI_data(0x04);
write_SPI_data(0x06);//0x08
write_SPI_data(0x15);//0x0A
write_SPI_data(0x10);
write_SPI_data(0x00);
write_SPI_data(0x31);//0x23
write_SPI_data(0x10);
write_SPI_data(0x15);//0x0A
write_SPI_data(0x06);//0x08
write_SPI_data(0x64);//0x74
write_SPI_data(0x0D);//0x0B
write_SPI_data(0x0A);//0x12
write_SPI_data(0x05);//0x08
write_SPI_data(0x0C);//0x06
write_SPI_data(0x31);//0x23
write_SPI_data(0x00);
write_SPI_commond(0x35);
write_SPI_data(0x00);
//write_SPI_commond(0x36);
//write_SPI_data(0x00);
write_SPI_commond(0x0C);
write_SPI_data(0x66);
write_SPI_commond(0x3A);
write_SPI_data(0x66);
write_SPI_commond(0x44);
write_SPI_data(0x00);
write_SPI_data(0x01);
write_SPI_commond(0xD0);
write_SPI_data(0x07);
write_SPI_data(0x07);//VCI1
write_SPI_data(0x14);//VRH 0x1D
write_SPI_data(0xA2);//BT 0x06
write_SPI_commond(0xD1);
write_SPI_data(0x03);
write_SPI_data(0x5A);//VCM  0x5A
write_SPI_data(0x10);//VDV
write_SPI_commond(0xD2);
write_SPI_data(0x03);
write_SPI_data(0x04);//0x24
write_SPI_data(0x04);
write_SPI_commond(0x11);
delay_nms(150);
write_SPI_commond(0x2A);
write_SPI_data(0x00);
write_SPI_data(0x00);
write_SPI_data(0x01);
write_SPI_data(0x3F);//320
write_SPI_commond(0x2B);
write_SPI_data(0x00);
write_SPI_data(0x00);
write_SPI_data(0x01);
write_SPI_data(0xDF);//480
//write_SPI_commond(0xB4);
//write_SPI_data(0x00);
delay_nms(100);
write_SPI_commond(0x29);
delay_nms(30);
write_SPI_commond(0x2C);

It also has a picture which says the LCD has one of several different controllers (and after digging in I know for a fact that two of mine were made by Raydium and are not on the list)

And finally a table of pins.  Which is interesting as it lists 37 pins when the shield has no where near that number.  And it shows the shield as  16-bit interface which it isnt … and it shows some LEDs which aren’t there either.

MCU Friend 3.5″ Shields

I bought 4 different shields.  One came broken.  The other three are all different.  When you look at the boards there are two visibly different configurations

  

Using the MCUFRIEND_kbv Library

The first thing I did was try to use the MCUFRIEND_kbv library to see if the screens worked.  The first board identified as ID=0x9403 and did not work.  Apparently, the tool just spits out the ID if it doesn’t know it, which it did not.

One of the boards identified as ID=0x6814 worked perfectly, and one had a blue cast to all of the screens.  The crazy part is the two boards that identified as ID=0x6814 had different PCBs.  According to the comments in the MCUFRIEND_kbv.cpp ID=0x6814 is an RM68140 and ID=9403 is unknown.

Here is the one with the blue cast:

Here is the functional one:

Identify with Register Reads

Next, I started down the path of trying to figure out what the controllers were by using register reads.  David Prentice (the guy who wrote/maintains the MCU Friend_kbv Arduino library) has an absolute ton of responses on the Arduino forum trying to help people figure out what their shield is.  He asks them to post the register report from his example program LCD_ID_readnew which is included as an example in the library.

When you look at these LCD controllers they all have some variant of “Read ID” which responds with 1-6 bytes.  The basic idea of this program is to look at what bytes are returned to try to identify the controller.  Here is an example of what I got when I ran the LCD_ID_readnew program on my shields:

reg(0x0000) 00 00       ID: ILI9320, ILI9325, ILI9335, ...
reg(0x0004) 54 54 80 66 Manufacturer ID
reg(0x0009) 00 00 61 00 00           Status Register
reg(0x000A) 08 08 Get Powsr Mode
reg(0x000C) 66 66 Get Pixel Format
reg(0x0030) 00 00 00 01 DF  PTLAR
reg(0x0033) 00 00 00 01 E0 00 00        VSCRLDEF
reg(0x0061) 00 00 RDID1 HX8347-G
reg(0x0062) 00 00 RDID2 HX8347-G
reg(0x0063) 00 00 RDID3 HX8347-G
reg(0x0064) 00 00 RDID1 HX8347-A
reg(0x0065) 00 00 RDID2 HX8347-A
reg(0x0066) 00 00 RDID3 HX8347-A
reg(0x0067) 00 00 RDID Himax HX8347-A
reg(0x0070) 00 00 Panel Himax HX8347-A
reg(0x00A1) 00 00 00 00 00    RD_DDB SSD1963
reg(0x00B0) 00 00 RGB Interface Signal Control
reg(0x00B3) 00 00 11 00 00      Frame Memory
reg(0x00B4) 00 00 Frame Mode
reg(0x00B6) 02 02 02 3B 00      Display Control
reg(0x00B7) 06 06 Entry Mode Set
reg(0x00BF) FF FF 68 14 00 FF   ILI9481, HX8357-B
reg(0x00C0) 0E 0E 0E 00 00 00 00 00 00   Panel Control
reg(0x00C1) 04 04 00 00 Display Timing
reg(0x00C5) 00 00 Frame Rate
reg(0x00C8) 00 00 00 00 00 00 00 00 00 00 00 00 00      GAMMA
reg(0x00CC) 00 00 Panel Control
reg(0x00D0) 00 00 00 00 Power Control
reg(0x00D1) 00 00 00 00 VCOM Control
reg(0x00D2) 00 00 00 Power Normal
reg(0x00D3) 00 00 94 86    ILI9341, ILI9488
reg(0x00D4) 00 00 00 00    Novatek
reg(0x00DA) 54 54 RDID1
reg(0x00DB) 80 80 RDID2
reg(0x00DC) 66 66 RDID3
reg(0x00E0) 00 00 54 07 44 05 08 00 54 07 44 05 08 44 44 00     GAMMA-P
reg(0x00E1) 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00     GAMMA-N
reg(0x00EF) 00 00 00 00 00 00 ILI9327
reg(0x00F2) 00 00 00 00 00 00 00 00 00 00 00 00 Adjust Control 2
reg(0x00F6) 00 00 00 00 Interface Control

The key thing to see in this output is the register 0x04 which says 54,80,66 which identifies this as a Raydium RM68140 LCD controller.  Here is a snapshot from the data sheet.

Unfortunately, the next thing to notice is that Register 0xBF has reg(0x00BF) FF FF 68 14 00 FF.  The unfortunate part is that this register is not documented in the data sheet beyond this one reference:

Presumably the “68 14” corresponds to a Raydium 68140, but who knows?  When I posted this on the Arduino forum, David Prentice responded (David does yeoman’s labor helping people and should be Thanked for all of his pro-bono work and putting up with a bunch of really bad questions)

After digging some more, I decided that it is super ugly out there, as you find that there are a significant number of LCD controllers that are clones, copies, pirated etc… and that they all present themselves differently.  And, in hindsight I think that this is the reason that my ILI9341 from the previous article doesnt quite work correctly.

A PSoC Program To Identify LCD Controllers

The next thing that I did was create a PSoC Program to read registers from the controllers to try to figure out what they were.  My original plan was to write a complete identification program, but I have largely decided that this is a waste of time (more on this later).  Here is the beginning of the project, it is called “Identify” in the workspace.

First, a function to reset the screen by toggling the reset line on the controller, then sending a command “0x01” which is commonly a software reset.   It turns out that I spent a bunch of time trying to figure out what was going on because I was not getting any responses from the controllers.  This was caused by not sending the software reset, which at least in two of the cases makes them unresponsive.

#define LCD_COMMAND (0)
#define LCD_DATA (1)
void lcdReset()
{
/* Reset - High, Low (reset), High */
Cy_GPIO_Set(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
CyDelay(200);
Cy_GPIO_Clr(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
CyDelay(200);
Cy_GPIO_Set(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
CyDelay(200);
GraphicLCDIntf_1_Write8(LCD_COMMAND,0x01);
}
void regReadPrint(uint8_t reg,uint8_t *buff,uint16_t num)
{
GraphicLCDIntf_1_Write8(LCD_COMMAND,reg);
GraphicLCDIntf_1_ReadM8(LCD_DATA,buff,num);
printf("%02X ",reg);
for(int i=0;i<num;i++)
{
printf("0x%02X,",buff[i]);
}
printf("\r\n");
}

Then I built a command line interface that queries the typical registers:

int main(void)
{
uint8_t buff[128];
__enable_irq(); /* Enable global interrupts. */
UART_Start();
setvbuf( stdin, NULL, _IONBF, 0 );
printf("Started\r\n");
GraphicLCDIntf_1_Start();
lcdReset();
while(1)
{
char c;
c=getchar();
switch(c)
{  
case 'a':
regReadPrint(0x04,buff,6);
regReadPrint(0xA1,buff,6);
regReadPrint(0xBF,buff,6);
regReadPrint(0xDA,buff,1);
regReadPrint(0xDB,buff,1);
regReadPrint(0xDC,buff,1);
regReadPrint(0xd3,buff,6);
break;

When I ran this program on the three controllers here is what I got:

Screen 1:
04 0x00,0x00,0x94,0x03,0x00,0x00,
A1 0x00,0x00,0x00,0x00,0x00,0x00,
BF 0x00,0x00,0x00,0x00,0x00,0x00,
DA 0x00,
DB 0x94,
DC 0x03,
D3 0x00,0x00,0x94,0x03,0x00,0x00,
Screen 2: Raydium 68140 (arduino works)
04 0x54,0x54,0x80,0x66,0x00,0x00,
BF 0xFF,0xFF,0x68,0x14,0x00,0xFF,
DA 0x54,
DB 0x80,
DC 0x66,
D3 0x00,0x00,0x94,0x86,0x00,0x00,
Screen 3: Raydium 68140 (looks blue)
04 0x54,0x54,0x80,0x66,0x00,0x00,
BF 0xFF,0xF7,0x60,0x14,0x00,0xFF,
DA 0x54,
DB 0x80,
DC 0x66,
D3 0x00,0x00,0x94,0x86,0x00,0x00,

So, where does this leave me?

1. I have no idea what Screen 1 is?  04 0x00,0x00,0x94,0x03,0x00,0x00,
2. Two of them appear to be Raydium RM68140s
3. The two Raydiums have different register values for 0xBF

And all of this is insane because most of these companies don’t appear to have coherent websites or generally available datasheets.  I suppose that it would help if I spoke and read Chinese.

Using the MCUFriend_kbv Startup Code

The next thing that I did was try out the startup code that MCUFriend_kbv generates.  I used the same technique from PSoC 6 + Segger EmWin + MCUFriend 2.4″ Part 1 and spit out the startup bytes.  Here they are:

0x1,0x0, 
0x28,0x0, 
0x3A,0x1,0x55, 
0x3A,0x1,0x55, 
0x11,0x0, 
0x29,0x0, 
0xB6,0x3,0x0,0x22,0x3B, 
0x36,0x1,0x8, 
0x2A,0x4,0x0,0x0,0x1,0x3F, 
0x2B,0x4,0x0,0x0,0x1,0xDF, 
0x33,0x6,0x0,0x0,0x1,0xE0,0x0,0x0, 
0x37,0x2,0x0,0x0, 
0x13,0x0, 
0x20,0x0, 

And this is what it looks like in my PSoC program:

static const uint8_t mcu35_init_sequence_kbv[]  = {
0x1,0x0,                            // Software Reset
0x28,0x0,                           // Display Off
0x3A,0x1,0x55,                      // Pixel Format Set 565
0x3A,0x1,0x55,                      // Pixel Format Set 565
0x11,0x0,                           // Sleep Out
0x29,0x0,                           // Display On
0xB6,0x3,0x0,0x22,0x3B,             // Display Function Control
0x36,0x1,0x8,                       // Memory Access Control
0x2A,0x4,0x0,0x0,0x1,0x3F,          // Column Set Address 320
0x2B,0x4,0x0,0x0,0x1,0xDF,          // Page Set Addres 480
0x33,0x6,0x0,0x0,0x1,0xE0,0x0,0x0,  // Vertical Scrolling Definition
0x37,0x2,0x0,0x0,                   // Vertical Scrolling Start Address
0x13,0x0,                           // Normal Display On
0x20,0x0,                           // Display Inversion Off
};

When I run this things look like this:

Screen 1: Looks good, just need to flip the x-axis

Screen 2: Looks good, just need to flip the y-axis

Screen 3: Not good… not exactly sure how to fix.

Use the Web Startup

Well, things still aren’t quite right, so for some strange reason, I keep going and try to use the startup code from the web.  In order to make it work I translate

• delay_nms –> CyDelay
• write_SPI_commond –> GraphicLCDIntf_1_Write8_A0
• write_SPI_data –> GraphicLCDIntf_1_Write8_A1

Here is the updated code:

static void _InitController35Web()
{
GraphicLCDIntf_1_Write8_A0(0xFF);
GraphicLCDIntf_1_Write8_A0(0xFF);
CyDelay(5);
GraphicLCDIntf_1_Write8_A0(0xFF);
GraphicLCDIntf_1_Write8_A0(0xFF);
GraphicLCDIntf_1_Write8_A0(0xFF);
GraphicLCDIntf_1_Write8_A0(0xFF);
CyDelay(10);
//0xB0,0x01,0x00,
GraphicLCDIntf_1_Write8_A0(0xB0); //0
GraphicLCDIntf_1_Write8_A1(0x00);
//0xB3,0x04,0x02,0x00,0x00,0x10,
GraphicLCDIntf_1_Write8_A0(0xB3); //1
GraphicLCDIntf_1_Write8_A1(0x02);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x10);
//0xB4,0x01,0x11,
GraphicLCDIntf_1_Write8_A0(0xB4); // 2
GraphicLCDIntf_1_Write8_A1(0x11);//0X10
// 0xC0,0x08,0x13,0x3B,0x00,0x00,0x00,0x01,0x00,0x43,
GraphicLCDIntf_1_Write8_A0(0xC0);
GraphicLCDIntf_1_Write8_A1(0x13);
GraphicLCDIntf_1_Write8_A1(0x3B);//
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x01);
GraphicLCDIntf_1_Write8_A1(0x00);//NW
GraphicLCDIntf_1_Write8_A1(0x43);
// 0xC1,0x04,0x08,0x15,0x08,0x08,
GraphicLCDIntf_1_Write8_A0(0xC1);
GraphicLCDIntf_1_Write8_A1(0x08);
GraphicLCDIntf_1_Write8_A1(0x15);//CLOCK
GraphicLCDIntf_1_Write8_A1(0x08);
GraphicLCDIntf_1_Write8_A1(0x08);
// 0xC4,0x04,0x15,0x03,0x03,0x01
GraphicLCDIntf_1_Write8_A0(0xC4);
GraphicLCDIntf_1_Write8_A1(0x15);
GraphicLCDIntf_1_Write8_A1(0x03);
GraphicLCDIntf_1_Write8_A1(0x03);
GraphicLCDIntf_1_Write8_A1(0x01);
// 0xC6,0x01,0x02
GraphicLCDIntf_1_Write8_A0(0xC6);
GraphicLCDIntf_1_Write8_A1(0x02);
// 0xC8,0x15,0x0C,0x05,0x0A,0x6B,0x04,0x06,0x15,0x10,0x00,0x31,0x10,0x15,0x06,0x64,0x0D,0x0A,0x05,0x0C,0x31,0x00
GraphicLCDIntf_1_Write8_A0(0xC8);
GraphicLCDIntf_1_Write8_A1(0x0c);
GraphicLCDIntf_1_Write8_A1(0x05);
GraphicLCDIntf_1_Write8_A1(0x0A);//0X12
GraphicLCDIntf_1_Write8_A1(0x6B);//0x7D
GraphicLCDIntf_1_Write8_A1(0x04);
GraphicLCDIntf_1_Write8_A1(0x06);//0x08
GraphicLCDIntf_1_Write8_A1(0x15);//0x0A
GraphicLCDIntf_1_Write8_A1(0x10);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x31);//0x23
GraphicLCDIntf_1_Write8_A1(0x10);
GraphicLCDIntf_1_Write8_A1(0x15);//0x0A
GraphicLCDIntf_1_Write8_A1(0x06);//0x08
GraphicLCDIntf_1_Write8_A1(0x64);//0x74
GraphicLCDIntf_1_Write8_A1(0x0D);//0x0B
GraphicLCDIntf_1_Write8_A1(0x0A);//0x12
GraphicLCDIntf_1_Write8_A1(0x05);//0x08
GraphicLCDIntf_1_Write8_A1(0x0C);//0x06
GraphicLCDIntf_1_Write8_A1(0x31);//0x23
GraphicLCDIntf_1_Write8_A1(0x00);
// 0x35,0x01,0x00
GraphicLCDIntf_1_Write8_A0(0x35);
GraphicLCDIntf_1_Write8_A1(0x00);
//GraphicLCDIntf_1_Write8_A0(0x36);
//GraphicLCDIntf_1_Write8_A1(0x00);
// 0x0C,0x01,x066
GraphicLCDIntf_1_Write8_A0(0x0C);
GraphicLCDIntf_1_Write8_A1(0x66);
//0x3A,0x01,0x55
GraphicLCDIntf_1_Write8_A0(0x3A);
GraphicLCDIntf_1_Write8_A1(0x55); // ARH changed to 565
//GraphicLCDIntf_1_Write8_A1(0x66);
// 0x44,0x02,0x00,0x01
GraphicLCDIntf_1_Write8_A0(0x44);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x01);
// 0xD0,0x04,0x07,0x07,0x14,0xA2,
GraphicLCDIntf_1_Write8_A0(0xD0);
GraphicLCDIntf_1_Write8_A1(0x07);
GraphicLCDIntf_1_Write8_A1(0x07);//VCI1
GraphicLCDIntf_1_Write8_A1(0x14);//VRH 0x1D
GraphicLCDIntf_1_Write8_A1(0xA2);//BT 0x06
// 0xD1,0x03,0x03,0x5A,0x10 
GraphicLCDIntf_1_Write8_A0(0xD1);
GraphicLCDIntf_1_Write8_A1(0x03);
GraphicLCDIntf_1_Write8_A1(0x5A);//VCM  0x5A
GraphicLCDIntf_1_Write8_A1(0x10);//VDV
// 0xD2,0x03,0x03,0x04,0x04,
GraphicLCDIntf_1_Write8_A0(0xD2);
GraphicLCDIntf_1_Write8_A1(0x03);
GraphicLCDIntf_1_Write8_A1(0x04);//0x24
GraphicLCDIntf_1_Write8_A1(0x04);
// 0x11,0x00,
GraphicLCDIntf_1_Write8_A0(0x11);
CyDelay(150);
// 0x2A,0x04,0x00,0x00,0x01,0x3F
GraphicLCDIntf_1_Write8_A0(0x2A);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x01);
GraphicLCDIntf_1_Write8_A1(0x3F);//320
// 0x2B,0x04,0x00,0x00,0x01,0xDF
GraphicLCDIntf_1_Write8_A0(0x2B);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x00);
GraphicLCDIntf_1_Write8_A1(0x01);
GraphicLCDIntf_1_Write8_A1(0xDF);//480
//GraphicLCDIntf_1_Write8_A0(0xB4);
//GraphicLCDIntf_1_Write8_A1(0x00);
CyDelay(100);
// 0x29,0x00
GraphicLCDIntf_1_Write8_A0(0x29);
CyDelay(30);
// 0x2C,0x00
GraphicLCDIntf_1_Write8_A0(0x2C);
}

Here is what I get:

Screen1: Looks good, but inverted (I know how to fix)

Screen 2: Looks right, except for the blue-line at the top (who knows)

Screen 3: Seriously jacked

Earlier I told you that I much preferred to use the more compact startup code.  In order to match this, I decided to add a new code “0xDD” which means delay.  (I hope that there are no controllers out there that use 0XDD).  Here is the updated function:

static void sendStartSequence(const uint8_t *buff,uint32_t len)
{
for(unsigned int i=0;i<len;i++)
{
if(buff[i] == 0xDD) // 
{
CyDelay(buff[i+1]);
i=i+1;
}
else
{
GraphicLCDIntf_1_Write8_A0(buff[i]);
i=i+1;
unsigned int count;
count = buff[i];
for(unsigned int j=0;j<count;j++)
{
i=i+1;
GraphicLCDIntf_1_Write8_A1(buff[i]);
}
}
}
}

And when I translate the web based startup code, here is what it looks like:

static const uint8_t mcu35_init_sequence_web[]  = {
0xFF,0x00,          // ?
0xFF,0x00,          // ?
0xDD,5,             // Delay 5
0xFF,0x00,          //
0xFF,0x00,          //
0xFF,0x00,          //
0xFF,0x00,          // ?
0xDD,10,            // delay 10
//  
0xB0,0x01,0x00,                                     // IF Mode control
0xB3,0x04,0x02,0x00,0x00,0x10,                      // Frame Rate Control - only 2 paramters
0xB4,0x01,0x11,                                     // Display inversion control 
0xC0,0x08,0x13,0x3B,0x00,0x00,0x00,0x01,0x00,0x43,  // Power Control 1
0xC1,0x04,0x08,0x15,0x08,0x08,                      // Power Control 2
0xC4,0x04,0x15,0x03,0x03,0x01,                      // ?
0xC6,0x01,0x02,                                     // ?
// ??
0xC8,0x15,0x0C,0x05,0x0A,0x6B,0x04,0x06,0x15,0x10,0x00,0x31,0x10,0x15,0x06,0x64,0x0D,0x0A,0x05,0x0C,0x31,0x00,
0x35,0x01,0x00,                     // Tearing Effect 
0x0C,0x01,0x66,                     // Read pixel format?
0x3A,0x01,0x55,                     // Pixel Format Set
0x44,0x02,0x00,0x01,                // Set Tear Scanline
0xD0,0x04,0x07,0x07,0x14,0xA2,      // NVM Write
0xD1,0x03,0x03,0x5A,0x10,           // NVM Protection Key
0xD2,0x03,0x03,0x04,0x04,           // NVM Status Read
0x11,0x00,                          // Sleep Out
0xDD,150,                           // Delay 150ms
0x2A,0x04,0x00,0x00,0x01,0x3F,      // Column Set Address 320
0x2B,0x04,0x00,0x00,0x01,0xDF,      // Page Set Address   480
0xDD,100,                           // Delay 100ms
0x29,0x00,                          // Display On
0xDD,30,                            // delay 30ms
0x2C,0x00                           // Memory Write
};

Notice that my comments on the commands show that there are a bunch of them I dont know what they mean.  Moreover, the MIPI spec says that all of the commands after 0xAF are reserved for the manufacturer… so I am pretty sure that they don’t do anything, or maybe should’nt be used?.  The last thing that I decide to do is edit out the stuff that does not seem to make sense.  Here is the new sequence:

static const uint8_t mcu35_init_sequence_web_edited[]  = {
0x35,0x01,0x00,                     // Tearing Effect 
0x3A,0x01,0x55,                     // Pixel Format Set
0x44,0x02,0x00,0x01,                // Set Tear Scanline
0x11,0x00,                          // Sleep Out
0xDD,150,                           // Delay 150ms
0x2A,0x04,0x00,0x00,0x01,0x3F,      // Column Set Address 320
0x2B,0x04,0x00,0x00,0x01,0xDF,      // Page Set Address   480
0xDD,100,                           // Delay 100ms
0x29,0x00,                          // Display On
0xDD,30,                            // delay 30ms
};

When I run this code I get the following screens:

Screen 1: Looks good, but inverted

Screen 2: Looks good (one of those codes created the blue line that is now gone)

Screen 3: Color screwed up

Conclusion

At this point I have spent a frightening amount of time figuring out how these screens work.  Although it has been a good learning experience, I have generally decided that using unknown displays from China with LCD drivers of questionable origin is not worth the pain of trying to sort out the interface.  Beyond that:

1. emWin seems to be able to talk to the RM68140 even though it is not listed as a supported chip
2. I have no idea what to do about screen 3.  Is it physically broken? Or do I just not know how to talk to it?
3. There many counterfeit chips out there.. and although they may work, it probably isnt worth the effort
4. David Prentice has added a lot of value for no personal gain by supporting the Arduino library MCUFriend_kbv

Embedded Graphics Index

Summary

In the previous Article (Part 1), I used an Arduino and two open source libraries to figure out the startup configuration sequence for a low cost 2.4″ TFT from MCUFriend.  In Part 2, I will show you how to use that information to make a driver for a PSoC 6 running the Segger emWin graphics library.

The steps that I will follow are:

1. Create an Example project for the CY8CKIT-028-TFT from CE223726 and test (make sure the emWin library works)
2. Copy the Example and Update Schematic and Pin Out for the MCUFriend Shield.
3. Modify the project and initialization code for the ILI9341
4. Test

Create an Example Project from CE223726 and Test

Cypress has delivered a code example for the CY8CKIT-028-TFT shield called CE223726.  This CE has all of the hardware connection setup for that shield, plus the integrated emWin middleware and a simple main that just displays 9 different screens.

The shield has a Newhaven 2.4″ 320×240 TFT with a Sitronix ST7789 driver.  This display uses the “8080” interface for the display, the same parallel interface as my MCUFriend shield.

To run the code example, first create a new project from the File->Code Example menu.

When you filter the list to “tft” by typing in the “Filter by” box you will see CE223726…. select it, then press “Create Project”.   If it is not on your computer you need to press the little world symbol to download it.

Accept the defaults for the Target IDE by pressing Next.

Give the project a sensible name, or accept the default name.

Once you have the project.  Program it to make sure that it works.

Copy the Example and Update Schematic and Pin Out

Now that I have the code example project tested, I will make a copy of it to serve as a base for the mcufriend version.  In the workspace explorer, select the project then Copy it with ctrl-c.  Next, click on the workspace and Paste with ctrl-v.  Then, rename the project to “mcufriend”.  Here is the workspace explorer after the copy/paste/rename.

The schematic for this project is interesting.  These LCDs use what is called the 8080 interface.  It was named 8080 because it is the same 8-bit interface that the old 8080 CPUs used.  Instead of using a “bit-banged” interface (like the Arduino implementation) Cypress created a digital component that knows how to write to the screen.  Actually this is bad-ass.  You can see that the component has D0-D7, Data/Command (D/C), Chip Select, Write (nwr) and Read (NRD).  Inside of the block there is a FIFO and a timing circuit that will let you write 8-bits at a time to the screen.

Now on with modifying the project.  First, you notice that the 2.4″ TFT shield has a different pin out than the CY8CKIT-028-TFT.  Here is a picture of the back of the shield:

To sort this out I created this pin map.  The other thing to notice is that the pin called “LCD_RS” is really the “LCD_C/D” pin.  I am not sure why they called it “RS” (well my friend Rajesh figured it out… RS means Register Select).  Anyway, here is a picture of the spreadsheet.  Another interesting thing to notice is that Cypress choose not to include the Chip Select on the pinout of the shield and in fact it is always selected.

All right, you can see that the pins are different, so, the first step in fixing this project is to remap the pins to match the shield.  Open up the Design Wide Resource pin configuration screen from the Workspace Explorer.  And assign the Shield Pins to the correct PSoC 6 pins.  Notice that I added a UART (which you can ignore)

The next thing that I need to do is update the schematic to reflect the ILI9341 speed.  On page 226 of the ILI9341 datasheet you can see that during a write cycle the write pulse needs to be low twrl=15ns and high twrh=15ns and the whole cycle needs to be at least 66ns.  For the read cycle the read pulse low trdl=45ns and the trdh=90ns.  Unfortunately, I dont know what an “FM” read is versus a “ID” read… so I am going to assume we only do “ID” reads.

The input clock to the LCD Interface component sets the width of the output write pulse.  Specifically, the write output is always low for 1 clock cycle and high for 1 clock cycle.  For instance, if your clock is set to 10MHz (also known as a period 100ns) then your write output pulse will be 100ns (low) + 100ns(high).  For the read pulse you are given the ability to set the number of clocks for low and high.  In the above case of a 10MHz input clock if you set the low to 3 and the high to 5 you would end up with 3*100ns  (low) + 5*100ns (high) = 800ns total.

Armed with all of that information, we need to pick 3 numbers.  An input clock, the # of read low pulse and the # of read high pulses.  The write cycle needs to be at least 66ns so we need a minimum clock frequency of 30MHz which will have a period of 33ns.  For the read we need 45ns low and 90ns high and a total of 160ns.  This means the whole read cycle needs to be 160ns/33ns=4.8 clock cycles.  To achieve this ill select 2 low (for 66ns) and 3 high (99 ns) total 165ns.

Open the schematic, then double click the clock and change its frequency to 30MHz.  (notice that I renamed it to LCD_Clock)

Double click the GraphicLCDIntf to update the read transaction low pulse to have 2-clocks and the read transaction high pulse width to be 3-clocks.

But wait.  Why is the pulse width 40ns and 80ns?  That means that the input clock is set to 25MHz (40ns period).  Well it turns out that is exactly right.  But if we typed in 30MHz how did we end up with 25MHz?  If you look on the clocks tab of the design wide resources you will find that the source of the LCD_Clock is the Clk_Peri and it is running at 50MHz.  When PSoC Creator figures out a clock, it can only choose a whole number divider, also known a 2 to synthesize the LCD_Clk, which means that the output frequency will actually be 25MHz.  I am pretty sure that I could move things around and figure out a combination of dividers and clock frequencies to make it work, but that isnt the point today so Ill just move forward.

Modify the Initialization Code

With the schematic and pin out modified, we will turn our attention to the code.  There are several changes that need to be made to LCDConf.c

1. Create a function called “_InitController_9341” to startup the screen (based on the learning from Part 1)
2. Change the name of function “_InitController” to be “_InitController_st7789”
3. Update the LCD_X_Config function with the correct orientation and color format
4. Update the function “LCD_X_DisplayDriver” to call the correct Initialization function

In order to get the screen going, you need to send the commands/data that we discovered in Part 1.  The author of that code had a structure which I like for holding that data.  Specifically it is an array of uint8_ts with Command, Length of Data , Data 0-N and on and on.  This is exactly the format that I spit out from the Arduino code in the Part 1.  Here is the screenshot:

To use this data I create an array (called ILI9341_regValues_2_4 … the same name from the original library.

static const uint8_t ILI9341_regValues_2_4[]  = {        // BOE 2.4"                                                                                                                
0x1,0x0,                                  // Software Reset
0x28,0x0,                                 // Display Off
0x3A,0x1,0x55,                            // Pixel Format RGB=16-bits/pixel MCU=16-bits/Pixel
0xF6,0x3,0x1,0x1,0x0,                     // Interface control .. I have no idea
#if 0    
0xCF,0x3,0x0,0x81,0x30,                   // Not defined
0xED,0x4,0x64,0x3,0x12,0x81,              // Not defined
0xE8,0x3,0x85,0x10,0x78,                  // Not defined
0xCB,0x5,0x39,0x2C,0x0,0x34,0x2,          // Not defined
0xF7,0x1,0x20,                            // Not defined
0xEA,0x2,0x0,0x0,                         // Not defined  
#endif
0xB0,0x1,0x0,                             // RGB Interface Control
0xB1,0x2,0x0,0x1B,                        // Frame Rate Control
0xB4,0x1,0x0,                             // Display Inversion Control
0xC0,0x1,0x21,                            // Power Control 1
0xC1,0x1,0x11,                            // Power Control 2
0xC5,0x2,0x3F,0x3C,                       // VCOM Control 1
0xC7,0x1,0xB5,                            // VCOM Control 2
0x36,0x1,0x48,                            // Memory Access Control
#if 0
0xF2,0x1,0x0,                             // Not defined
#endif
0x26,0x1,0x1,                             // Gamma Set
0xE0,0xF,0xF,0x26,0x24,0xB,0xE,0x9,0x54,0xA8,0x46,0xC,0x17,0x9,0xF,0x7,0x0,    // Positive Gamma Correction
0xE1,0xF,0x0,0x19,0x1B,0x4,0x10,0x7,0x2A,0x47,0x39,0x3,0x6,0x6,0x30,0x38,0xF,  // Negative Gamme Correction
0x11,0x0,                                 // Sleep Out
0x29,0x0,                                 // Display On
0x36,0x1,0x48,                            // Memory Access Control
0x2A,0x4,0x0,0x0,0x0,0xEF,                // Column Address Set = 239
0x2B,0x4,0x0,0x0,0x1,0x3F,                // Row Address Set  = 319
0x33,0x6,0x0,0x0,0x1,0x40,0x0,0x0,        // Vertical Scrolling Definition
0x37,0x2,0x0,0x0,                         // Vertical Scrolling Start Address
0x13,0x0,                                 // Normal Display ON
0x20,0x0,                                 // Display Inversion OFF
};

Notice that I have ifdef’d out the values that dont do anything.  In order to use the array, I create a function called _InitController_9341.  It

1. Starts the component
2. Sends a reset
3. Then loops through the datastrcture from above sending Write Commands (GraphicLCDIntf_1_Write8_A0) and Write Data (GraphicLCDIntf_1_Write8_A1)

static void _InitController_9341(void)
{
/* Start the parallel interface */
GraphicLCDIntf_1_Start();
/* Reset - High, Low (reset), High */
Cy_GPIO_Set(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
GUI_Delay(20);
Cy_GPIO_Clr(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
GUI_Delay(100);
Cy_GPIO_Set(LCD_RESET_N_0_PORT, LCD_RESET_N_0_NUM);
GUI_Delay(100);
for(unsigned int i=0;i<sizeof(ILI9341_regValues_2_4);i++)
{
GraphicLCDIntf_1_Write8_A0(ILI9341_regValues_2_4[i]);
printf("Command %02X\r\n",ILI9341_regValues_2_4[i]);
i=i+1;
unsigned int count;
count = ILI9341_regValues_2_4[i];
for(unsigned int j=0;j<count;j++)
{
i=i+1;
printf("Data %02X\r\n",ILI9341_regValues_2_4[i]);
GraphicLCDIntf_1_Write8_A1(ILI9341_regValues_2_4[i]);
}
}
}

Now we move onto the configuration function.  There are several changes that need to be made to it.

1. What driver chip you are using?
2. What is the bus interface you are going to use?
3. What is the format of the RGB Data?
4. How do you want the screen setup?

The function call on line 319 configures the driver and the bus interface.

GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B8);

The driver is specified from table 33.42 on page 1193 of the emWin manual.  Specifically, you tell it to use GUIDRV_FLEXCOLOR_F66709 which you can see support ILI9341 amongst others.

Then you need to tell what bus interface to use.  When we setup the display, we told it that we wanted 16-bit color by sending 0x3A, 0x55.  Here is a screen shot from the ILI9341 datasheet.

Given that, the last parameter of the driver call is the bus format.  So, set the bus width to 16 bits per pixel, 8-bit bus.

GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B8);

Now you need to tell it what bits mean what color.  For this display 16-bit color is encoded at 5-bits of Red, 6-bits of Green and 5-bits of Blue.  On Page 65 of the ILI9341 datasheet you can see that we should send 8-bits of command, 5 bits of red, 6-bits of green, 5-bits of blue, then the next pixel.

To tell emWin that, you need to pick GUICC_M565 (see the screen shot below from the Segger emWin documentation)

But it turns out that doesnt work?  The blue and green are FLIPPED.  How is that possible?  As I tried to figure this out I googled a bunch of things… read on the Segger forums etc.  All of the normal things.  Finally I sent a note to some of my friends at Cypress that went like this:

“There are several possibilities

1. There is a bug in emWin
2. There is a bug in the ILI9341
3. There is a bug in the emWin documentation
4. There is a bug in the ILI9341 documentation
5. There is a bug in my firmware
6. There is a bug in my brain.
7. There is a bug in my understanding of the documentation

Personally I bet on #7″

Well it turned out that I was right.  It was #7.  The Red-Green-Blue order is set by register 36h

If you recall I copied setup from the Arduino code in Part 1.  When I called the setup I wrote 0x48 into that register… that is also known as BGR = 1 or “1=BGR color filter panel”.  It turns out that the example of the byte writing order above is just that… and example.  How did I figure this out?  Simple answer, thank you to Oleksandr in Ukraine for sorting that out for me because I was going out of my mind last night.

Now, the other little nasty part of things is that if I had written BGR=0 it still would not have worked.  It turns out that emWin overwrites that bit when it rotates the screen.  Why?  Who the hell knows.  Anyway, here is what Oleksandr says, “In your code in the initialization sequence you set 0x36 register to 0x48 so, BRG mode must be active and GUICC_565 palette must be correct.  But FlexColor driver itself writes to the 0x36 register in order to setup display orientation. By default, driver set the BRG bit to zero, activating RGB mode.”  Here is a rather vague description of what happens from the emWin documentation. [There is still an error here]

With the color order sorted out, the last thing that I change is the orientation of the display on line 309.  Here is the entire configuration function:

void LCD_X_Config(void) {
GUI_DEVICE * pDevice;
CONFIG_FLEXCOLOR Config = {0};
GUI_PORT_API PortAPI = {0};
//
// Set the display driver and color conversion
//
// GUICC_565
// GUICC_M565
pDevice = GUI_DEVICE_CreateAndLink(DISPLAY_DRIVER, GUICC_565, 0, 0);
//
// Display driver configuration
//
LCD_SetSizeEx    (0, XSIZE_PHYS,   YSIZE_PHYS);
LCD_SetVSizeEx   (0, VXSIZE_PHYS,  VYSIZE_PHYS);
//
// Orientation
//
//Config.Orientation   = GUI_MIRROR_Y | GUI_SWAP_XY;
Config.Orientation   = GUI_SWAP_XY;
GUIDRV_FlexColor_Config(pDevice, &Config);
//
// Set controller and operation mode
//
PortAPI.pfWrite8_A0  = GraphicLCDIntf_1_Write8_A0;
PortAPI.pfWrite8_A1  = GraphicLCDIntf_1_Write8_A1;
PortAPI.pfWriteM8_A1 = GraphicLCDIntf_1_WriteM8_A1;
PortAPI.pfRead8_A1  = GraphicLCDIntf_1_Read8_A1;
PortAPI.pfReadM8_A1  = GraphicLCDIntf_1_ReadM8_A1;
GUIDRV_FlexColor_SetFunc(pDevice, &PortAPI, GUIDRV_FLEXCOLOR_F66709, GUIDRV_FLEXCOLOR_M16C0B8);
}

In the LCD_X_DisplayDriver function I will simply call the correct initialization function… the one we just created … called _InitController_9341

int LCD_X_DisplayDriver(unsigned LayerIndex, unsigned Cmd, void * pData) {
int r;
GUI_USE_PARA(LayerIndex);
GUI_USE_PARA(pData);
switch (Cmd) {
case LCD_X_INITCONTROLLER: {
//
// Called during the initialization process in order to set up the
// display controller and put it into operation. If the display
// controller is not initialized by any external routine, this needs
// to be adapted by the customer...
//
// ...
_InitController_9341();
return 0;
}
default:
r = -1;
}
return r;
}

Test

Finally a program and test… and lookey here… it works:

You can find all of these projects on my github site: https://github.com/iotexpert/MCUFriend or clone it with git clone git@github.com:iotexpert/MCUFriend.git

Embedded Graphics Index

Summary

This article takes you through the steps that I went through to figure out the startup sequence for a 2.4″ TFT MCUFriend display (Part 1), and then port it to a PSoC 6 running Segger emWin graphics library (Part 2)

I recently tried out the Cypress CY8CKIT-028-TFT with the PSoC Creator Example Project, CE223726.  This code example builds a project using the Segger EmWin library, its pretty cool.  And, I have been interested in LCDs so I purchased some random LCD shields from eBay, including a rather generic looking 2.4″ TFT from bang good (a generic Chinese reseller).  The entirety of the documentation is silkscreen plus the sticker you see in the picture, which just tells you that it has an ILI9341 LCD driver.

  

This left me with a number of questions  Starting with, How do you initialize the screen?  Obviously you can find the Ilitech ILI9341 datasheet, but then what?  The datasheet has fifty billion parameters, and not much advice about what to do.  Moreover, after googling around, I discovered that there is an absolute rogues gallery of bad advice about these screens.  Horrible horrible.  Finally, I found an Arduino library called “MCUFRIEND_kbv” that seemed like it was coherent.  So, I installed it and got the screen working – just to prove that it worked.  But I’m still not going to use an Arduino, so I need to port the initialization to my Segger emWin project.

Here is what I did to sort this out:

1. Install the Arduino libraries to use the 2.4″ TFT MCUFriend Shield
2. Fix & Run the Arduino Example project to prove that it works
3. Modify the MCUFRIEND_kbv.c to dump the ILI9341 Startup sequence
4. Verify the startup sequence against the ILI9341 data sheet (and fix the errors)
5. Modify the CE223726 to use the ILI9341 shield

Install the Arduino Libraries

In order to use the screen I need the Arduino libraries that drive it.  Start by installing the Adafruit GFX library select Sketch–>Include Library–>Manage Libraries…

In the filter box type “gfx”.  Once you find the Adafruit GFX Library, you can click Install.

Then you need to install mcufriend_kbv library.  Type “mcuf” into the filter.  Then select install.

These two operations will add the directories to your library:

Fix & Run the Arduino Example project

After you have added the Libraries, you can then make a project based on one of the MCUFriend existing examples.  For this test case Ill pick File–>Examples–>MCUFRIEND_kbv–>diagnose_TFT_support

For this project to run you need to include the AdafruitGFX library. To do that select Sketch–>Include Library–>Adafruit GFX Library

And also the SPI library with Sketch–>Include Library–>SPI

Once that is done you can click on the build checkmark, then the download button and your screen should look something like this:

And you should have this:

And if you start the serial port monitor you will get this:

OK.  This is good.  This means that the screen is functioning and the Arduino library properly identifies it as a ILI9341.

Modify the MCUFRIEND_kbv.cpp

In order to get one of these screens going you need to set a bunch of parameters before you can attach it to your Graphics library.  But, what is the sequence.  I first started looking through the code…. but honestly it is a mess.  Here is a little snip of it:

case 0x9341:
common_9341:
_lcd_capable = AUTO_READINC | MIPI_DCS_REV1 | MV_AXIS | READ_24BITS;
static const uint8_t ILI9341_regValues_2_4[] PROGMEM = {        // BOE 2.4"                                                                                                                
0xF6, 3, 0x01, 0x01, 0x00,  //Interface Control needs EXTC=1 MV_EOR=0, TM=0, RIM=0                                                                                                     
0xCF, 3, 0x00, 0x81, 0x30,  //Power Control B [00 81 30]                                                                                                                               
0xED, 4, 0x64, 0x03, 0x12, 0x81,    //Power On Seq [55 01 23 01]                                                                                                                       
0xE8, 3, 0x85, 0x10, 0x78,  //Driver Timing A [04 11 7A]                                                                                                                               
0xCB, 5, 0x39, 0x2C, 0x00, 0x34, 0x02,      //Power Control A [39 2C 00 34 02]                                                                                                         
0xF7, 1, 0x20,      //Pump Ratio [10]                                                                                                                                                  
0xEA, 2, 0x00, 0x00,        //Driver Timing B [66 00]                                                                                                                                  
0xB0, 1, 0x00,      //RGB Signal [00]                                                                                                                                                  
0xB1, 2, 0x00, 0x1B,        //Frame Control [00 1B]                                                                                                                                    
//            0xB6, 2, 0x0A, 0xA2, 0x27, //Display Function [0A 82 27 XX]    .kbv SS=1                                                                                                 
0xB4, 1, 0x00,      //Inversion Control [02] .kbv NLA=1, NLB=1, NLC=1                                                                                                                  
0xC0, 1, 0x21,      //Power Control 1 [26]                                                                                                                                             
0xC1, 1, 0x11,      //Power Control 2 [00]                                                                                                                                             
0xC5, 2, 0x3F, 0x3C,        //VCOM 1 [31 3C]                                                                                                                                           
0xC7, 1, 0xB5,      //VCOM 2 [C0]                                                                                                                                                      
0x36, 1, 0x48,      //Memory Access [00]                                                                                                                                               
0xF2, 1, 0x00,      //Enable 3G [02]                                                                                                                                                   
0x26, 1, 0x01,      //Gamma Set [01]                                                                                                                                                   
0xE0, 15, 0x0f, 0x26, 0x24, 0x0b, 0x0e, 0x09, 0x54, 0xa8, 0x46, 0x0c, 0x17, 0x09, 0x0f, 0x07, 0x00,
0xE1, 15, 0x00, 0x19, 0x1b, 0x04, 0x10, 0x07, 0x2a, 0x47, 0x39, 0x03, 0x06, 0x06, 0x30, 0x38, 0x0f,
};

Rather than try to figure out all of the stuff that I “THINK” that it sends, I decided to modify the WriteCmdParamN method to just print out what it actually sends.  And I decided to print it out in a format that would be easy to import into my program:  You can see that each time a command is sent, I print out the command number, followed by the number of bytes, followed by the actual bytes (this is similar to the original code).

#define ARH_DEBUG
void MCUFRIEND_kbv::WriteCmdData(uint16_t cmd, uint16_t dat) { writecmddata(cmd, dat); }
static void WriteCmdParamN(uint16_t cmd, int8_t N, uint8_t * block)
{
#ifdef ARH_DEBUG
Serial.print(F("0x"));
Serial.print(cmd,HEX);
Serial.print(F(",0x"));
Serial.print(N,HEX);
Serial.print(F(","));
#endif
CS_ACTIVE;
WriteCmd(cmd);
while (N-- > 0) {
uint8_t u8 = *block++;
#ifdef ARH_DEBUG
Serial.print(F("0x"));
Serial.print(u8,HEX);
Serial.print(F(","));
#endif
write8(u8);
if (N && is8347) {
cmd++;
WriteCmd(cmd);
}
}
#ifdef ARH_DEBUG
Serial.println(F(" "));
#endif
CS_IDLE;
}

When I download and run the program you can see that it

1. Issues a reset
2. Then sends the commands/data to configure the screen

OK thats good.  Now, the bad part, when I look at the commands in the ILI9341 documentation it turns out that 0xCF, 0xED, 0xE8, 0xCB, 0xF8, 0xEA and 0xF2 are not actually commands.  Hmmm… I suppose that they don’t do any harm?  But they also don’t appear to actually do anything.  I guess beggars can’t be choosers, so I won’t be critical.

In the next Article I’ll show you how to take this startup code and put it into a PSoC with Segger emWin.

Embedded Graphics Index