1
\$\begingroup\$

As we are developing our application based on the PIC18F66K22. We need to interface LCD with it. We have the LCD working with it but the problem that we are getting is that the LCD initialization takes around 10 Sec and only after that the LCD starts till then even microcontrooller does not execute any commands.But after initialization it works as expected without any delay. What might be causing the problem ? The LCD controller is ili9163C. The datasheet can be found at https://www.displaytech-us.com/sites/default/files/driver-ic-data-sheet/ILI9163C_DS_V010_2011_0118.pdf .

The following is the initialization code.

void LCD_init()
{
Send_Command(0x11); //Exit Sleep   
delay_ms(50);   
Send_Command(0x26); //Set Default Gamma   
Send_Data(0x04);   
// Send_Command(0xF2); //E0h & E1h Enable/Disable   
// Send_Data(0x00);   
Send_Command(0xB1);   
Send_Data(0x0C);   
Send_Data(0x14);   
Send_Command(0xC0); //Set VRH1[4:0] & VC[2:0] for VCI1 & GVDD   
Send_Data(0x0C);   
Send_Data(0x05);   
Send_Command(0xC1); //Set BT[2:0] for AVDD & VCL & VGH & VGL   
Send_Data(0x02);   
Send_Command(0xC5); //Set VMH[6:0] & VML[6:0] for VOMH & VCOML   
Send_Data(0x29);   
Send_Data(0x43);   
Send_Command(0xC7);   
Send_Data(0x40);   
Send_Command(0x3a); //Set Color Format   
Send_Data(0x55);   
Send_Command(0x2A); //Set Column Address   
Send_Data(0x00);   
Send_Data(0x00);   
Send_Data(0x00);   
Send_Data(0x7F);   
Send_Command(0x2B); //Set Page Address   
Send_Data(0x00);   
Send_Data(0x00);   
Send_Data(0x00);   
Send_Data(0x9F);   
Send_Command(0x36); //Set Scanning Direction   
Send_Data(0xA8);   
Send_Command(0xB7); //Set Source Output Direction   
Send_Data(0x00);   
Send_Command(0xf2); //Enable Gamma bit   
Send_Data(0x01);   
Send_Command(0xE0);   
Send_Data(0x36);//p1   
Send_Data(0x29);//p2   
Send_Data(0x12);//p3   
Send_Data(0x22);//p4   
Send_Data(0x1C);//p5   
Send_Data(0x15);//p6   
Send_Data(0x42);//p7   
Send_Data(0xB7);//p8   
Send_Data(0x2F);//p9   
Send_Data(0x13);//p10   
Send_Data(0x12);//p11   
Send_Data(0x0A);//p12   
Send_Data(0x11);//p13   
Send_Data(0x0B);//p14   
Send_Data(0x06);//p15   
Send_Command(0xE1);   
Send_Data(0x09);//p1   
Send_Data(0x16);//p2   
Send_Data(0x2D);//p3   
Send_Data(0x0D);//p4   
Send_Data(0x13);//p5   
Send_Data(0x15);//p6   
Send_Data(0x40);//p7   
Send_Data(0x48);//p8   
Send_Data(0x53);//p9   
Send_Data(0x0C);//p10   
Send_Data(0x1D);//p11   
Send_Data(0x25);//p12   
Send_Data(0x2E);//p13   
Send_Data(0x34);//p14   
Send_Data(0x39);//p15   
Send_Command(0x29); // Display On
}

This is the main section

void main()
{
OSCCONbits.IRCF0 = 1;   //HFINTOSC 16MHz with PLLEN
OSCCONbits.IRCF1 = 1;
OSCCONbits.IRCF2 = 1;
OSCTUNEbits.PLLEN = 1;
delay_ms(5);
while(!OSCCONbits.IRCF2);   //wait for HF-INTOSC oscillator frequency is stable
delay_ms(5);
    Config_IO();
    lcd_reset();    //LCD reset
delay_ms(5);    //LCD reset complete delay`
    LCD_init();
font_init();

    TRISBbits.TRISB3 = 0;
TRISCbits.TRISC2 = 0;
RELAY_EN = 0;

FillFullLcd(WHITE);
//LCD_image (0,33,159,96,(unsigned char rom *)benchmark);
// sprintf(&FirmVerText[6],"%d.%d",FW[0]-0x30,FW[1]-0x30);
// setfont((void *)font_Calibri_10);
// LCD_OutText(50,97,FirmVerText,BLACK);
setfont((void *)font_Calibri_10); //added by shailesh
    LCD_OutText(50,99,FirmVerText,BLACK);//added by shailesh
    LCD_image (0,33,159,96,(unsigned char rom *)benchmark);
    delay_ms(3000);
    FillFullLcd(BLUE);
    Hstart = 0;
    Vstart = 0;
    radius = 5;
    Hend = 100;
    Vend = 75;
    color = BLUE;
LCD_draw_round_corner_box(2,33,157,96,75,LOGOC,1);
//LCD_Rectangle(2,33,157,96,LOGOC,1);
LCD_OutText(35,55, productstr,WHITE);
    delay_ms(2000);
    calibration();
    while(1);
    }

Here in this code it takes around 10 sec to paint the entire screen blue. but after that all the lcd operations are working perfectly fine and without delay. What might be causing the problem here ?

\$\endgroup\$
  • \$\begingroup\$ Added the code and the uC supports 16 MIPS. \$\endgroup\$ – Jimit Jun 24 '13 at 8:20
  • 1
    \$\begingroup\$ @CamilStaps Yes, the uC is running at full 64 MHz. We also have other LCD working with this uC but this particular LCD controller is causing the issues. \$\endgroup\$ – Jimit Jun 24 '13 at 8:35
  • \$\begingroup\$ That's useful information. The other LCDs, are they the same (i.e. same part number)? That makes it likely that you have a broken LCD. \$\endgroup\$ – Keelan Jun 24 '13 at 8:45
1
\$\begingroup\$

It is really hard to tell from your posted code, much of which is missing, what could be consuming all the time.

You'll need to do some work to narrow down just where all the delays are. A tried and true way to do this is to find an I/O pin that is currently idle or not used and set it up as an output DEBUG pin. Then start setting this pin high and then back low at various points in your code wake up and initialization flows. Putting this signal on an oscilloscope along with the MCU Reset signal will let you characterize how long various parts of the code are taking to run.

Within a short time you will be able to determine if it is the MCU oscillator startup code, the length of time it takes to run the LCD init routine or how long it takes to run the FillFullLcd() routine. <- These are just examples. It could be something else.

\$\endgroup\$
0
\$\begingroup\$

delays should be defined 2-5ms froom enable to preamble and 20-50 for latch after initialization command then a larger one after initialization for control commands always sustaining enable pin delays for each case depending the interfacing ex. hc164... enable to low should maybe also be preceded by a short delay to ensure display controller has latched.

\$\endgroup\$
-1
\$\begingroup\$

Actually we have solved this problem. The problem was caused by the 50 ms delay after "wake up from the sleep" command. After removing the delay the LCD is now working perfectly fine. I guess the 50 ms delay is causing the LCD controller to wake up from the sleep.

\$\endgroup\$
  • \$\begingroup\$ This is not a good idea. The controller needs this delay to exit the sleep condition. It might work, but that's likely due to other things in your code. 'Solving' it this way might cause unexpected problems later on. \$\endgroup\$ – Keelan Jun 24 '13 at 10:37
  • \$\begingroup\$ @CamilStaps We think its unlikely that after successful initialization it will cause any problem. We have also tested all the required functionality for our project. Also the LCD manufacture has recommendation written in his code that adjust the delays according to your clock requirement. So this is probably the better solution. Thanks again for your valuable comments. \$\endgroup\$ – Jimit Jun 24 '13 at 10:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.