CFAF176220M with PIC18F4550

cpefrank

New member
I am working on a project and I am new at working with GLCD's. I have PIC18F4550 which will be loading an image onto the CFAF176220M. The example for the CFAF176220M shows pin layouts for the AVR setup and a crystalfontz admin said he hasnt worked with PIC's before. So is any one familiar with using the CFAF176220M and maybe can answer questions regarding my setup?

I will be using PORTD on the PIC for the D0-D7 on the CFAF176220M.
The other connections are as follows:

PIC <-> CFAF176220M

RA0 <-> Reset
RA1 <-> RD
RA2 <-> WR
RA3 <-> RS
RA4 <-> CS


The CFAF176220M example in the datasheet shows:
#define LCD_RESETPC2
#define LCD_RD PC5
#define LCD_WR PC6
#define LCD_RS PC7
#define LCD_CS PC4
#define LED_1 PD1
#define LED_2 PD2
// macros for control lines
#define CLR_RS PORTC &= ~(1<<LCD_RS);
#define SET_RS PORTC |= (1<<LCD_RS);
#define CLR_CS PORTC &= ~(1<<LCD_CS);
#define SET_CS PORTC |= (1<<LCD_CS);
#define CLR_RESET PORTC &= ~(1<<LCD_RESET);
#define SET_RESET PORTC |= (1<<LCD_RESET);
#define CLR_WR PORTC &= ~(1 << LCD_WR);
#define SET_WR PORTC |= (1 << LCD_WR);
#define CLR_RD PORTC &= ~(1 << LCD_RD);
#define SET_RD PORTC |= (1 << LCD_RD);
#define LED1_OFF PORTD &= ~(1 << LED_1);
#define LED1_ON PORTD |= (1 << LED_1);
#define LED2_OFF PORTD &= ~(1 << LED_2);
#define LED2_ON PORTD |= (1 << LED_2);


And my "modified" one looks like:
//control lines
#define LCD_RESET LATAbits.LATA0
#define LCD_RD LATAbits.LATA1
#define LCD_WR LATAbits.LATA2
#define LCD_RS LATAbits.LATA3
#define LCD_CS LATAbits.LATA4
#define LED_1 LATEbits.LATE0
#define LED_2 LATEbits.LATE1
#define LED_3 LATEbits.LATE2

#define LCD_DATA LATD

// macros for control lines
#define CLR_RS PORTA &= ~(1<<LCD_RS);
#define SET_RS PORTA |= (1<<LCD_RS);

#define CLR_CS PORTA &= ~(1<<LCD_CS);
#define SET_CS PORTA |= (1<<LCD_CS);

#define CLR_RESET PORTA &= ~(1<<LCD_RESET);
#define SET_RESET PORTA |= (1<<LCD_RESET);

#define CLR_WR PORTC &= ~(1 << LCD_WR);
#define SET_WR PORTC |= (1 << LCD_WR);
#define CLR_RD PORTC &= ~(1 << LCD_RD);
#define SET_RD PORTC |= (1 << LCD_RD);

#define LED1_OFF PORTE &= ~(1 << LED_1);
#define LED1_ON PORTE |= (1 << LED_1);
#define LED2_OFF PORTE &= ~(1 << LED_2);
#define LED2_ON PORTE |= (1 << LED_2);
#define LED3_OFF PORTE &= ~(1 << LED_3);
#define LED3_ON PORTE |= (1 << LED_3);

Thanks for looking thru that, also:
What is the meaning of the LED1_ON/OFF
Arnt the backlight LEDS on as soon as i turn the LCD on?

Thanks for your responses, Frank.
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
What is the meaning of the LED1_ON/OFF
Arnt the backlight LEDS on as soon as i turn the LCD on?
As is shown in the data sheet, the 3 backlight LEDs are powered separately from the logic and I/O. They only turn on if you supply (current limited) power to the 3 LED anode pins (and have the K pin grounded).

BTW, you can avoid having your text clipped by the web site if you put "code" tags around it. Highlight the code portion, and press the "#" control at the top of the editor.
 

cpefrank

New member
As is shown in the data sheet, the 3 backlight LEDs are powered separately from the logic and I/O. They only turn on if you supply (current limited) power to the 3 LED anode pins (and have the K pin grounded).

BTW, you can avoid having your text clipped by the web site if you put "code" tags around it. Highlight the code portion, and press the "#" control at the top of the editor.
Thanks for the reply, I was going to connect the LED anode pins to a separate 3.2v power source with 10ohm resistors (min is 6.66ohm). Therefore I thought that the backlights will be on as soon as I connect the voltage source and resistors and ground, which means the LEDs have nothing to do with my PIC pin connections. That's why I was wondering why the example has them being controlled by the AVR controller.
 
I was going to connect the LED anode pins to a separate 3.2v power source with 10ohm resistors...
Since the forward voltage of the LEDs is about 3.2 volts, they probably won't light up with 3.2v applied. You need to use a higher voltage, such that the resistor(s) drop [ps voltage] - 3.2v at 15 mA current.

As for your pin assignments, they look OK, without seeing more of your code, not much can be supposed. One thing to watch out for is that your timing (delays, pulse widths, etc) is not faster that what the data sheet calls out as minimum.

The sample code for this display has defines for 2 LEDs on PORTD. I believe these are not backlight controls, but rather LEDs mounted on a demo board.
 

cpefrank

New member
ok the back lights are working correctly, my dev board supplies VR10k and put 3.2v on leds/Vlogiv and 1.8v on the voltage for I/O signals (Vlogic I/O).

the image does not appear , im not sure exactly if i even have data transferring here's my code so far:

Code:
/*
PINS
LCD     PIC
RST     RA0 wired reset
RD      RA1 active low, L:Read; use with WR pin
WR      RA2 active low, L:Write; use with RD pin
RS      RA3 1=data , 0=cmd
CS      RA4 chip select, low active

*/

#include <p18cxxx.h>
#include "background.h"

//setting the pragma
#pragma config PLLDIV = 5 //5 for 20MHz input
#pragma config CPUDIV = OSC4_PLL6 //96/6=16MHz clock for Vdd=3.3v
#pragma config USBDIV = 2 //usb clock source /2
#pragma config FOSC = HSPLL_HS //hs osc with PLL enbl
#pragma config PWRT = ON //power up timer on
#pragma config BOR = OFF // no brown out reset
#pragma config VREGEN = OFF //no usb voltage regulator
#pragma config WDT = OFF //no watch dog timer
#pragma config MCLRE = ON //enbl mclr
#pragma config PBADEN = OFF //port b 0,1,2,3 I/O rst
#pragma config STVREN = ON //enbl stack overflow rst
#pragma config LVP = OFF //no low vltg prog 
#pragma config ICPRT = ON //I.C.P.
#pragma config DEBUG = ON //enbl background debugr

//set pin configuration
#define TRIS_LCD_WR	TRISAbits.TRISA2	//WR pin 
#define LCD_WR		LATAbits.LATA2
#define TRIS_LCD_RS	TRISAbits.TRISA3	//control cmd/data
#define LCD_RS		LATAbits.LATA3	
#define TRIS_LCD_CS	TRISAbits.TRISA4	//CS pin 
#define LCD_CS		LATAbits.LATA4	
#define TRIS_LCD_RD	TRISAbits.TRISA1	//RD pin 
#define LCD_RD		LATAbits.LATA1

//#define TRIS_LCD_BL	TRISAbits.TRIS	//LCD backlight control 
//#define LCD_BL		LATAbits.LAT

#define TRIS_LCD_DATA   TRISD			//LCD 8-bit data port to PORTD	
#define LCD_DATA		LATD
#define LCD_PORT		PORTD


void delay();
void write_cmd(unsigned char cmd);
void write_data(unsigned char data_h,unsigned char data_l);
void display_color(unsigned char data_h,unsigned char data_l);
void init_display();
void display_background(unsigned char x, unsigned char y, const rom unsigned int *pPat);
void display_pixel(unsigned char x, unsigned char y, unsigned int color);

void main(){
    init_display();
    delay(32767);//98.31ms
    display_background(0,0,&background[0]);
    
}
/********functions*********/
void delay (unsigned int x)
{
	unsigned int i;
	for (i = 0; i < x ; i++)
		;
}
void write_cmd(unsigned char cmd){
    LCD_CS=0;
    LCD_RS=0;
    LCD_RD=1;
    LCD_WR=1;
    LCD_DATA=0x00;
    LCD_WR=0;
    LCD_WR=1;
    LCD_DATA=cmd;
    LCD_WR=0;    
    LCD_WR=1;
    LCD_CS=1;
    LCD_RS=1;
}
void write_data(unsigned char data_h,unsigned char data_l){
    LCD_CS=0; // chip selected
    LCD_RS=1; // set to write data
    LCD_RD=1; // not reading
    LCD_WR=1; // not writing yet
    LCD_DATA=data_h; // write the cmd to the port
    LCD_WR=0; // bring write line low
    LCD_WR=1; // clock in the cmd
    LCD_DATA=data_l; // write the cmd to the port
    LCD_WR=0; // bring write line low
    LCD_WR=1; // clock in the cmd
    LCD_CS=1; // unselect chip
    LCD_RS=1; // set for data
}
void display_color(unsigned char data_h,unsigned char data_l){
    unsigned int i, j;
    write_cmd(0x20);
    write_data(0x00,0x00);
    write_cmd(0x21);
    write_data(0x00,0x00);
    write_cmd(0x22);
    for(i=0;i<220;i++)
    {
        for(j=0;j<176;j++)
        {
            write_data(data_h,data_l);
        }
    }
    
}
void init_display(){
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x00,0x18);      // Booster circuits not started automatically, controlled through PON0-3
                                // Generate VCI1, VCI1 = +2.58v
    write_cmd(0x12);            // Power Control 3 (P22-23, OTM2201A Datasheet)
    write_data(0x00,0x00);      // Generate VGH VCI1 x 5 (13.75v) / VGL VCI1 x -3 (-8.25v)
                                // Freq. of step up 1 = 1:4, Freq. of step up 2 = 1:2, Freq. of step up 3 = 1:4
    write_cmd(0x13);            // Power Control 4 (P23-25, OTM2201A Datasheet)
    write_data(0x00,0x63);      // clock cycle of external (RGB) interface (as default, unused)
                                // Gamma voltage (GVDD < AVDD (VCI1*2)-0.3v) 1100011 = GVDD Voltage +4.45v
    write_cmd(0x14);            // Power Control 5 (P14, OTM2201A Datasheet)
    write_data(0x55,0x6A);      // VCOMG = 0 ( Amplitude of VCOM = |VCOMH-VCOML| ), VCOMH = GVDD x 0.8690
                                // VCMR = 0 (VCOMH determined by VCM6-0), VCOMH = GVDD x 1.074
    write_cmd(0x10);            // Power Control 1 (P21, OTM2201A Datasheet)
    write_data(0x08,0x00);      // Constant current in op-amp Medium Fast 1
                                // Not in stand by, not in deep stand by
    delay(8350);//50ms
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x01,0x18);      // Start booster circuit 1
                                // Generate VCI1, VCI1 = +2.58v
    delay(8350);//50ms
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x03,0x18);      // Booster circuit 1 on, start VGH circuit
                                // Generate VCI1, VCI1 = +2.58v
    delay(8350);//50ms
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x07,0x18);      // Booster circuit 1, VGH on, start VGL circuit
                                // Generate VCI1, VCI1 = +2.58v
    delay(8350);//50ms
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x0F,0x18);      // Booster circuit 1, VGH, VGL on, Start VCL circuit
                                // Generate VCI1, VCI1 = +2.58v
    delay(8350);//50ms
    write_cmd(0x11);            // Power Control 2 (P22, OTM2201A Datasheet)
    write_data(0x0F,0x38);      // Booster circuit 1, VGH, VGL on, Start VCL circuit
                                // Start amplifier circuit, Generate VCI1, VCI1 = +2.58v
    delay(8350);//50ms
    write_cmd(0x07);            // Display Control (P17, OTM2201A Datasheet)
    write_data(0x00,0x12);      // FLM output disabled
                                // Gate output Enabled, Normally black 
    write_cmd(0x07);            // Display Control (P17, OTM2201A Datasheet)
    write_data(0x00,0x1A);      // FLM output disabled
                                // Gate output Enabled, 8 color mode selected, Normally black
    write_cmd(0x01);            // Driver Output Control Register (P14, OTM2201A Datasheet)
    write_data(0x01,0x1C);      // Decrement Address counter
                                // 528x220 dots (176xRGBx220)
    write_cmd(0x03);            // Entry Mode (P16, OTM2201A Datasheet)
    write_data(0x10,0x30);      // BGR (reversed color bits)
                                // Increment automatically the address counter
    write_cmd(0x07);            // Display Control (P17, OTM2201A Datasheet)
    write_data(0x00,0x00);      // FLM output disabled
                                // Gate output disabled
    write_cmd(0x08);            // Blanking Control (P18, OTM2201A Datasheet)
    write_data(0x08,0x08);      // 8 lines for the front porch
                                // 8 lines for the back porch
    write_cmd(0x15);            // VCI Period (P28, OTM2201A Datasheet)
    write_data(0x00,0x20);      //
                                // Sn=2, Vcom1=1/2, Vcom2=2/1, RGB=16dot clock
    write_cmd(0x36);            // Horizontal Window Address 1 (P32, OTM2201A Datasheet)
    write_data(0x00,0xAF);      // Set the horizontal start position of a window for memory access
                                // 175
    write_cmd(0x37);            // Horizontal Window Address 2 (P33, OTM2201A Datasheet)
    write_data(0x00,0x00);      // Set the horizontal end position of a window for memory access
                                // 0
    write_cmd(0x38);            // Vertical Window Address 1 (P33, OTM2201A Datasheet)
    write_data(0x00,0xDB);      // Set the vertical start position for memory access
                                // 219
    write_cmd(0x39);            // Vertical Window Address 1 (P33, OTM2201A Datasheet)
    write_data(0x00,0x00);      // Set the vertical end opsition of a window for memory access
                                // 0
    write_cmd(0x50);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x00,0x01);
    write_cmd(0x51);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x02,0x08);
    write_cmd(0x52);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x08,0x05);
    write_cmd(0x53);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x04,0x04);
    write_cmd(0x54);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x0c,0x0c);
    write_cmd(0x55);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x00,0x0c);
    
    write_cmd(0x56);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x01,0x00);
    write_cmd(0x57);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x04,0x00);
    write_cmd(0x58);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x11,0x08);
    write_cmd(0x59);            // Gamma Control (P34, OTM2201A Datasheet)
    write_data(0x05,0x0c);
    write_cmd(0x0F);            // Oscillator Control (P21, OTM2201A Datasheet)
    write_data(0x0F,0x01);         // Freq = 453kHz x 1.29
                                // Oscillator on
    write_cmd(0x07);            // Display Control (P17, OTM2201A Datasheet)
    write_data(0x00,0x12);      // FLM output disabled
                                // Gate output Enabled, Normally black
    write_cmd(0x07);            // Display Control (P17, OTM2201A Datasheet)
    write_data(0x00,0x17);      // FLM output disabled
                                // Gate output Enabled, Normal display, gate on, vcom on, display on
            
    delay(58000);delay(58000);  //500ms
    
    write_cmd(0x22);            // GRAM Data (P30, OTM2201A Datasheet)   
}
void display_background(unsigned char x, unsigned char y, const rom unsigned int *pPat){
	 	unsigned int   col, row, pWidth, pHeight, pixel;

	pWidth  = pPat[0];
	pHeight = pPat[1];

	for(row=0;row<pHeight;row++)
		{	
			for(col=0;col<pWidth;col++)
			{
				pixel = pPat[col+row*pWidth+2];
				display_pixel(col+x,row+y,pixel);
			}
		}
}
void display_pixel(unsigned char x, unsigned char y, unsigned int color)
{
	unsigned char hiByte, lowByte;
	x = 176-1-x;
	y = 220-1-y;

	hiByte  = color>>8;
	lowByte = (unsigned char)color;

	write_cmd(0x42);		//X-address area set in the 160 pixel direction (y-axis)
	write_cmd(y);						//offset for scan COM from 0~159
	write_cmd(y++);
	write_cmd(0x43);		//Y-address area set in the 128 pixel direction (x-axis)
	write_cmd(x);						//offset for scan SEG from 0~127
	write_cmd(x++);

	write_data(hiByte,lowByte);	

	
}
thanks for helping, much appreciated,
frank.
 
I see that you don't have any delays in your I/O routines. What is the clock speed of your cpu (16 MHz ?), and what is the write pulse width?

Do you have access to an oscilloscope to verify that your signals are reaching the display?
 

cpefrank

New member
cpu speed is 20MHz
write pulse width, i'm not sure what it is, can this be determined in MPLAB IDE?

and yes I do have access to an oscilloscope if I bring my things to campus, but not at this moment


now where should there be delays for the I/O?

thanks
 
I think you may be OK with timing. At 20 MHz clock, and 1 clock cycle per instruction, I believe, the time between I/O events should be about 50 nS. The data sheet calls for write pulse minimum of 33 nS, and a write cycle time of 100 nS. If you wanted to insert delays to see if there is any difference, you would put them here:
Code:
void write_cmd(unsigned char cmd){
    LCD_CS=0;
    LCD_RS=0;
    LCD_RD=1;     // unnecessary to do this every time
    LCD_WR=1;     // unnecessary to do this every time since WR is left at 1 state
    LCD_DATA=0x00;
    LCD_WR=0;
    // insert 50 nS delay here to stretch WR pulse
    LCD_WR=1;
    // insert 50 nS delay here to stretch WR cycle time
    LCD_DATA=cmd;
    LCD_WR=0;    
    // insert 50 nS delay here to stretch WR pulse
    LCD_WR=1;
    LCD_CS=1;
    LCD_RS=1;     // unnecessary to do this every time since next function sets it
}
You would do the same thing in both the command and the data write functions. A 50 nS delay could be as simple as a NOP instruction [_asm("NOP");]

The thing you would want to look for with the scope is the signal quality at the input to the display. This is important that you hook your ground to the display input. See if there is any noise on the signal, such as ringing, or odd voltage levels, indicating perhap a high resistance connection or shorted signal lines or a poor quality ground. By putting a cycling test pattern on the data and control ports, you can check for mis-wiring.
 

cpefrank

New member
Thanks,
I will add the 50ns delays, the write command function you see is the one from the example in the data sheet of the LCD, except they used macros instead of say 1 and 0. And I'll comment out the redundant lines.

The funny thing atm is that when I program the chip and try to re-read it the hex file it is all 0000's, and found out that it is data and code protected. I cant really find where to turn this off. I need to read the #pragma configs again.

Instead of trying to put a background image up maybe I should write a text or something.
The display_pixel and display_background are similar to another example I have been learning from, some one used the PIC18F4550 with a different LCD and related it to mine.

Maybe relating the two is conflicting; but it seemed correct to me.

I'm with your knowledge we will figure this out.
 
Instead of trying to put a background image up maybe I should write a text or something.
Ha ha, you're kidding, right? This controller has no native text capability, AFAIK. The way text is done on graphic displays is you have an array of bitmap images of each character, and you copy them to the display at the proper row and column. If you want to see a sample of that kind of code, you can search the forums for my user name and the topic of "CFAF320240" and/or "CFAF240400".

But I guess getting the lock bit erased and reprogramming your chip is the first order of business. I won't offer help with that because I'm not all that familiar with (nor a fan of) PIC cpus.
 

cpefrank

New member
Sorry I forgot to mention that I changed the 1.8v realizing the V I/O logic = Vlogic*0.7...

but, one thing is that the data sheet says the V I/O logic is I/O and I have disconnected the external power source and the V I/O logic spits out 3v... I ran some tests and if I use an initialize_port() for my MCU it makes the V I/O logic spit out 3v but if I do not use the initialize_port() function it does not output 3v

Is it ok to have the V I/O logic output 3v? and run the PS and LED (+) off of the 3v?

Anyway,
I see results when the GLCD is initialized and if I put in a while(1) loop, attempting to change a pixel, the screen also responds

I attempted the display_color() function again and nothing shows up. Screen just flickers slightly.

Thanks
 
Sorry I forgot to mention that I changed the 1.8v realizing the V I/O logic = Vlogic*0.7...
I don't know what you mean by this. I would connect both the Vlogic and VlogicI/O together, to the 3.2 V supply.
but, one thing is that the data sheet says the V I/O logic is I/O and I have disconnected the external power source and the V I/O logic spits out 3v... I ran some tests and if I use an initialize_port() for my MCU it makes the V I/O logic spit out 3v but if I do not use the initialize_port() function it does not output 3v
The CFA part of the data sheet says VlogicI/O is bidirectional, but the OTM2201 data sheet makes no such claim. I would not regard that pin as an output.
Is it ok to have the V I/O logic output 3v? and run the PS and LED (+) off of the 3v?
I have the feeling that if 3 V appears on the VlogicI/O pin (if not otherwise connected), it is incidental, and that pin is not designed to source any significant current.
Anyway, I see results when the GLCD is initialized and if I put in a while(1) loop, attempting to change a pixel, the screen also responds
Well, please, tell us just what the response of the screen is.
I attempted the display_color() function again and nothing shows up. Screen just flickers slightly.
Going back yet again to the suggestion about verifying your signal level and timing on a scope, have you done that?

There are lots of things that must be correct for this to work; if one aspect is bad, you get no result. I don't have enough information about your situation to give more specific advice.
 

cpefrank

New member
I figured it out, I didnt initialize both ports I was using so only the data port was enabled output, now I have tested a few colors and it worked perfectly.

Thanks so much for the help, the oscillator helped to figuring out that data port was working but the other one wasnt.

As I continue with my project I will update you with anymore troubles or successes.

Thanks again!
 

cpefrank

New member
Ugh, yes that is what I meant, sorry.

I got an image up but its all disfigured, something is wrong with the way it is decoded into hex, or my code is backwards in some way.
Code:
void display_bg(unsigned char x, unsigned char y, const rom unsigned int *pPat)
{
 	unsigned int   col, row, pWidth, pHeight, pixel;

	pWidth  = pPat[0];
	pHeight = pPat[1];
    write_command(0x20);
    write_data(0x00,0x00);
    write_command(0x21);
    write_data(0x00,0x00);
    write_command(0x22);

	for(row=0;row < pHeight;row++)
		{	

			for(col=0;col < pWidth;col++)

			{
				
				pixel = pPat[col+row*pWidth+2];
				write_data(pixel>>8,(unsigned char)pixel);
				
			}
		}	
}
*****it seems wrapping the "code" on this code doesnt work... so i left it unwrapped.****

So I have this image with the starting 2 hex numbers giving the size, therefore pWidth+2, then the colors start right after. This image has 4 hex digits per color such as 0xFFFF. So thats why I have it shifting >>8.

One thing is that image2lcd.exe produces only 2 hex digit colors, such as 0xFF, which needs to be split into data_hi and data_low for write_data. I havent modded this code to fit the 2 hex color code yet.

The thing thats bugging me is that when the image is placed on the screen its always repeating over and over, while shifting up. It wont stop, I think I need a pixel counter, and when it reaches the end of a pixels break out.

I'm still working on it, but if you have any suggestions I would love to here them ; ).
You are a king on this forum, cosmicvoid. ; )
(Edited by moderator)
 
... I think I need a pixel counter, and when it reaches the end of a pixels break out...
"The end of a pixels"... that is another baffler. Seems to me, your code has two for() loops, which is your pixel counter.

Without seeing the original image, and your converted image data array, I can't comment on why your image is "disfigured"; care to explain it more completely?

This might happen if pHeight and pWidth are not equal to the height and width of the display. Do you have a way to single step thru your program, to see if the data is what you expect? I am unclear what the size of an "int" is in your code; is it 16 bits?
One thing is that image2lcd.exe produces only 2 hex digit colors, such as 0xFF, which needs to be split into data_hi and data_low for write_data. I havent modded this code to fit the 2 hex color code yet.
I don't understand this part, either. Sounds like your data array may not be the right size (?). Too little info given to speculate further.
 

cpefrank

New member
Ok your right, I do count the pixels with the two for loops. But the image still repeats over and over (shifting a tad up).

This is the beginning part of a sample image with what I meant had 4 digit hex:

const rom unsigned int icon[7742]={0x005A,0x0056,0xFFFF,0xFFFF,0xFFFF,0xFFFF.. etc

this is what I meant by 2 digit hex coming from image2lcd.exe:

const rom unsigned int background[2470] = { 0X00,0X01,0XDC,0X00,0X58,0X00,0XFF,0XFF.. etc

The write_data needs data_hi and data_lo... so clarify this for me since RRRR RGGG GGGB BBBB is the color bits, data_hi = RRRR RGGG and data_lo = GGGB BBBB, right?

So for the sample image icon[7742] is has 4 digits 0xFFFF and I used pixel>>8 for data_hi and (unsigned char)pixel for data_lo... this is correct right?

Now for image2lcd.exe it only prints out 2 digits 0xFF and not 4 so I'm in the middle of rewriting the function for that kind of image.

I've been busy with exams coming up, but I will try any suggestions given.

The main goal of the GLCD is to have a back ground image in place at all times but with a few areas where smaller dynamic images will be changing.

Thanks again
 
const rom unsigned int icon[7742]={0x005A,0x0056,0xFFFF,0xFFFF,0xFFFF,0xFFFF.. etc
So you are taking an image that is 90 * 86 pixels, and smearing it across a display that is 176 * 200 pixels, and you wonder why it is disfigured. What you need to do is after each row of 90 pixels, set the cursor address to the beginning of the next row. It appears that the address registers are not divided into horiz addr and vert addr, but rather a 16 bit linear address, so you would have to calculate (row * 176) and then send the low byte to register 0x20 and the high byte to register 0x21. I could be wrong on this, as I do not have this display to experiment with.
The write_data needs data_hi and data_lo... so clarify this for me since RRRR RGGG GGGB BBBB is the color bits, data_hi = RRRR RGGG and data_lo = GGGB BBBB, right?
Seems right to me.
So for the sample image icon[7742] is has 4 digits 0xFFFF and I used pixel>>8 for data_hi and (unsigned char)pixel for data_lo... this is correct right?
Seems right to me.
Now for image2lcd.exe it only prints out 2 digits 0xFF and not 4 so I'm in the middle of rewriting the function for that kind of image.
const rom unsigned int background[2470] = { 0X00,0X01,0XDC,0X00,0X58,0X00,0XFF,0XFF.. etc
How are you going to expand the 8 bit values to 16 bits? Is there some color encoding in the 8 bits (e.g. 3:3:2)? It seems like 2470 pixels in the background array is insufficient to fill a display with 35200 pixels.
 

cpefrank

New member
How are you going to expand the 8 bit values to 16 bits? Is there some color encoding in the 8 bits (e.g. 3:3:2)? It seems like 2470 pixels in the background array is insufficient to fill a display with 35200 pixels.
Wait a minute... Maybe it's already split up as data_hi and data_lo... the CF support person said they use image2lcd.exe so maybe I read it as {data_hi,data_lo,data_hi,data_lo,} etc... That will support the 16 bit color scheme.

Now back to the icon.h image... the image comes in rotated 90 degree clockwise, and skewed so much is barely recognizable but I can faintly see the pattern.

I'll be working on this tomorrow after my exam and will test it with the image2lcd image with 2 digit hex.

Thanks
 

cpefrank

New member
It is already split up for data_h and data_l... a 20x20 pixel image turns out to be 800 hex numbers in 0xFF,0xFF instead of 400 hex numbers in 0xFFFF... I'm still working on a working function to display an image.
 
Top