• We recently switched our forum platform. If you experience any issues please email support@crystalfontz.com

CFAF176220M with PIC18F4550

cpefrank

New member
Another thing is that CF support said to "reset the RAM address at the end of each row", if you have suggestions on how to do this, I would love them = ) but I have the function now reading in the image from image2lcd.exe using the data_h,data_l as the 0xFF,0xFF not the 0xFFFF.

Thanks
Looking for additional LCD resources? Check out our LCD blog for the latest developments in LCD technology.
 
Another thing is that CF support said to "reset the RAM address at the end of each row"
I think that he means the same thing that I suggested earlier, that when you have written one row of pixels (i.e. the number of columns in the image), then set the RAM address to the beginning of the next display row.
 

cpefrank

New member
Hi again, I'm not sure if this thread is outdated now, but I have a question about displaying the images on the GLCD.

Is there a way to instantly display the image and not have it run one pixel at a time...

Say I need real time numbers to display, say with a potentiometer varying the voltage to an analog input will change numbers instantly on the GLCD...

Also I ran into a problem with having multiple images as header files for example:
#include image1.h
#include image2.h
#include image3.h

if i display:
image1 then image2 then imag3 all in different locations... the image 1 appears but image2 and image3 turn out to be what was stored as image 1...image1 seems to be saved or something...

i am currently working on displaying multiple images in different locations and to have an analog input changing numbers (as close to real time as possible)

Thanks, if i need to make a new thread let me know.
 
This thread is not outdated, so you don't need to start a new one. I'd say maybe a month of no posting might outdate a thread, but its usually easier to keep a topic in one thread than to have to go back and find old threads to remember whats been said.
Is there a way to instantly display the image and not have it run one pixel at a time...
All writes are done "one pixel at a time", but its been my experience that unless you have excessive delays in your code, the update rate is acceptably fast. If you really need fast updates, say like for video, you would need to use the RGB interface, which is not implimented on this module. So, there is no way to make the update be "instant". You could speed things up a little by optimizing your data write function by eliminating unnecessary statements, and perhaps putting the code inline.
Also I ran into a problem with having multiple images as header files for example:
#include image1.h
#include image2.h
#include image3.h

if i display:
image1 then image2 then imag3 all in different locations... the image 1 appears but image2 and image3 turn out to be what was stored as image 1...image1 seems to be saved or something...
I'm not sure why you would put images in a header file (instead of a .c file). And I can't offer any advice without seeing what your code looks like. If you decide to post your code, and its longer than 30 or 40 lines, better to attach it (them) as a text file(s) or in a zip file.
 

cpefrank

New member
So for the data write function it looks as follows:

Code:
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
	delay(50);  	//50ns

  LCD_DATA=data_h; // write the command to the port
	delay(50);		//50ns

  LCD_WR=0;       // bring write line low
  LCD_WR=1;       // clock in the command
	delay(50);		//50ns

  LCD_DATA=data_l; // write the command to the port
	delay(50);		//50ns

  LCD_WR=0;       // bring write line low
  LCD_WR=1;       // clock in the command

  LCD_CS=1;       // unselect chip
  //LCD_RS=1;       // set for data
}
Writing pixels is pretty fast, but I haven't had a chance to test the varying voltage into an analog input yet to test the speed of erasing a number, rewriting a number over top of it..

And for the images the example I have seen had the image in a header file... So is there a way to put all the images into one file? Or do I need a .c file for each image? I currently read images as such:

const rom unsigned char icons[1320] = { 0X00, 0X48, 0X00, 0X70, 0X00, 0X98, 0X22, 0XC8, etc.
This represents the first 4 pixels. The image is 30x22 = 660 pixels = 1320/2.

I am stuck with the char size colors, 'cuz image2lcd.exe only prints it this way...

Thanks!
 
I find it curious that you didn't put the delays in the same places that I suggested in my modification of your write_data() & write_command() code. Why did you move them?

You could make a short version of your write_data() function, for use when transfering images. In that version, there is no reason to keep setting RS to 1, and there is no reason to change CS at all, just leave it active all the time. The only thing the function would have is [dataH to bus] [toggle WR] [dataL to bus] [toggle WR], done. If you put those statements inline in your image write loop, then you save the cpu time of doing a call and return each for write.
Writing pixels is pretty fast, but I haven't had a chance to test the varying voltage into an analog input yet to test the speed of erasing a number, rewriting a number over top of it..
So you're saying you don't know yet whether your screen update is too slow or not. You may find that when dealing with analog inputs, you need to do some filtering (averaging) to get rid of quantization jitter.
And for the images the example I have seen had the image in a header file... So is there a way to put all the images into one file? Or do I need a .c file for each image?
Data storage declaration in header files is not "wrong", it is just not standard practice. You can also #include .c files, too, ya know?

You can put the images all in one file, or separate files, it doesn't matter. Just add those files to your project, so they are compiled along with your main module (if you haven't used the #include method).
I am stuck with the char size colors, 'cuz image2lcd.exe only prints it this way...
No big deal, since you have to make 2 writes per pixel anyway.
 

cpefrank

New member
Oh, sorry I didnt realize I messed up the delays, I'll fix those now...

As for the making those extra function calls for each pixel in the image, your so right when you can put the data to bus inline with writing the image function. Thanks, I thought of it in the past, but when I'm not familiar with something I usually follow examples closely and the data sheet example calls it with all those extra RS and CS commands. This is much better.

Would it be wise to have a #include "images.h" and inside images.h will have included image1.c image2.c image3.c, etc.? I still dont know why when I compiled all the images (that were in .h) along with my main module that when printing the images the first one just printed again and again like it needs to be cleared out before printing a different image or something.

Thanks a bunch
 
If it was me doing your project, I would not have any of the image related files be includes; I would just make them .c files and add them to the project list. Since I don't know what kind of development environment you are using, I cannot make specific suggestions.

As to why all three images have the image1 data, I cannot say without seeing your code, as I said earlier. So thats old news, right?
 

cpefrank

New member
Ok, I followed your suggestion and made 2 images as .c and added both to the source files. One white and one red image.

I printed both images, red first white second... Same stuff happened... Red displayed, but the white image was all messed up and RED. I printed the white first then the red and the white displayed fine and the red image was messed up and was WHITE.

It seems I need to clear where the stored image was used to print, then use the next image.

So its not old news 'cuz it still happens. Any suggestions?

in main:
display_bg(0,0,24,32,&"white.c"[0]);
display_bg(50,0,17,22,&"red.c"[0]);

display_bg:
Code:
void display_bg(unsigned char x,unsigned char y,unsigned char pWidth,unsigned char pHeight,const rom unsigned char *pPat)
{
 	unsigned int col, row,pixel;

	pixel =1;
	for( row = 0 ; row < pHeight ; row++)
		{	
			for(col = 0 ; col < pWidth ; col++)
			{
    			write_command(0x20);
    			write_data(0x00 , x + col);
    			write_command(0x21);
    			write_data(0x00 , y + row);
    			write_command(0x22);

				write_data( pPat[ pixel ] , pPat[ pixel + 1 ] );
				pixel = pixel + 2;
				
			}
		}				
				
}
The "pixel" deal works this way the best... unless you have better suggestions, but I have printed other images using this function.

This is the original image function not with the faster use of write data.

Thanks for the help !
 
Actually, what is old news is that I keep asking you to post your code, and you continue to decline to do so. Like maybe you are afraid that I might find out why your program isn't working as expected. Well, I see you have relented, and posted a snippet.

I see that you don't "get it" as far as setting the RAM address. You only have to set it to the beginning of the row (column x), and the controller will automatically increment the address on each successive write. Setting the address for each pixel is a HUGE HUGE waste of time, and would only be necessary if you are writing to non-sequential locations.

I would be interested to see your code for the "delay(50)" fifty nanosecond delay. I think that just a call + return, with nothing in the function, would probably use up 50 nS.

I have modified your routine:
Code:
void display_bg(unsigned char x, unsigned char y,
                unsigned char pWidth, unsigned char pHeight,
                const rom unsigned char *pPat)
{
    unsigned int col, row;

    LCD_CS = 0;        // chip selected

    for( row = 0 ; row < pHeight ; row++)
    {
        write_command(0x20);
        write_data(0x00 , x);        // lower 8 bits of addr = col
        write_command(0x21);
        write_data(0x00 , row + y);  // upper 8 bits of addr = row
        write_command(0x22);
        LCD_RS = 1;                     // set to write data

        for(col = 0 ; col < pWidth ; col++)
        {
            LCD_DATA = *pPat++;     // write the data to the port
            LCD_WR=0;            // bring write line low
            delay(50);            //50ns
            LCD_WR=1;            // clock in the data

            delay(50);                //50ns

            LCD_DATA = *pPat++;    // write the data to the port
            LCD_WR=0;            // bring write line low
            delay(50);            //50ns
            LCD_WR=1;            // clock in the data
        }
    }                
    LCD_CS = 1;       // chip deselected
}
Note that I don't have this display, and have no experience with this particular controller, so I could be mistaken about the RAM address hi/lo bytes. But I have a lot of experience with other CFA TFT displays, and the programming is very similar on them. Look at the data sheet, table 5-21 on page 67, to see the addressing method.
 

cpefrank

New member
Ok before we get into your version of the code, I went back and made sure I commented out the correct ones you told me were unnecessary in write_data and write_command.. and nothing worked... I uncommented them and the display worked... So for some reason it is necessary to keep the RD, WR, RS extra commands in there. So we must follow that sample write/command function.

No image printed with your code snippet, I will try to mod it by using those terms (RD,WR,RS) I commented out before ... Unless you beat me to it.

The delay is just a for loop I ran in MPLAB c18 and measured the time with the stopwatch. And it happen to be 50 loops to be 50ns...

Thanks for making more sense of the "inline" code, I tried it myself but it didnt work...
 
So for some reason it is necessary to keep the RD, WR, RS extra commands in there.
Hence the reason for me requesting your WHOLE program, so that I have some clue as to what state those signals might be left in from previous functions. There is no inherent reason to keep those commands in there unless your program is leaving them in the wrong state.
The delay is just a for loop I ran in MPLAB c18 and measured the time with the stopwatch. And it happen to be 50 loops to be 50ns...
Impossible. That would require 1 nS per loop, which would need a cpu running at well over 1GHz clock speed. I expect you are confusing nanoseconds with microseconds.
 

cpefrank

New member
You pretty much saw the whole program. It's all the functions from the sample code that I need to write data, write commands, and initialize display. Then there is the display_bg() was the one we were talking about before. So if any, the display_bg function would be leaving the signals in the wrong state.

As for the 50ns delay... Sorry I forgot to change that, I did realize it wasnt 50ns when I figured the same as you did, I have the #define nop() _asm nop _endasm , (forgot to change out the delay(50), but it turns out to be 1 microsecond. I know my cpu speed is 20MHz , which is 50ns... So what else can get me 50ns?
Man that makes me feel dumb, talking about the delay(50) when I forgot to change it!...

I just get so occupied in other tasks and classes, I mess up sometimes... Not that it matters but I did get a 100 on my digital signal procs. exam.. and a 102 on my electronic 2 exam : )

But now to focus on this matter, so you said it, I dont get how to reset the RAM after I display an image... That's probably why the first image turns out to be the second image. I'm trying to figure it out from the datasheet, is it called GRAM?

Thanks, sorry for some mistakes.
 
Ok, I guess you don't want to make it easy for me. I don't much care to keep looking back to earlier pages of the thread for fragments of code. If you don't care to attach your zipped code files, then I think I'm done here.
 

cpefrank

New member
Ok files are attached...
Thanks for holding on to the forum..

I do appreciate the help.

Now I'm working on figuring out how to reset the ram so I can display multiple images so that the others images after the first one being the same as the first one.

BTW I finally put in the nop(); in the write data and command and the images are now pretty much instant onto the display.

Thanks.
 

Attachments

cpefrank

New member
I changed a couple things.
In function display_bg()... I took out the pixel thing and put *pPat++... you had it in your example and also its better to just increment the address.
 
Its interesting to look at your files; I see some errors that your compiler should have gagged on. I also see that your code for "display_bg()" was taken from the initial post (or the notification email), and not the edited post that appeared a few minutes later. I am guessing you just ignored what was in the code box I posted.

Errors:
Code:
&[SIZE="6"]"[/SIZE]image01.c[SIZE="6"]"[/SIZE][0]
variable names do not have quotation marks in them.

I can see why your two images have the same content:
Code:
    display_bg(55,55,14,16,&"[B]image[COLOR="Red"]01[/COLOR].c[/B]"[0]);
    display_bg(0,10,14,16,&"[B]image[COLOR="Red"]01[/COLOR].c[/B]"[0]);
I guess you don't know how to type image02.

In your image files, there is a comma after the final byte which should not be there.

I have attached your files with my modifications.
 

Attachments

cpefrank

New member
Ugh, I have been using other images that I am going to use, those image01 and image02 are just something I created right after you asked to see files... I have used other images with different names and the second image was still messed up... As you can see I rushed setting up an example to send files, my mistake.

The image2lcd.exe makes those files and if there is a comma after the image I left it there, images still printed fine. Yet the only problem was that the second image did not.

As said previously I did use your sample display image and it did not work at that point so I commented it out and tested more images I am designing with my old image image display function.

Sorry for all my mistakes...

I tested your sample code.

After putting in the modded code, the LCD does not work, but I used the old write_data write_command function and your display_bg function worked perfectly. But I do need " " around the source name or the project doesnt build. Now testing two images, using the old write_data and old write_command it still does not print correctly and yes they both have totally different names.

I followed your version of write data and command and it seems fine. I still need to figure out why the extra signals need to be there in order to make them work.

Taking the commas out of the end of the image files did not change anything.

There has got to be a way to clear the ram before each image.

Thanks again for the fast responses!
 

cpefrank

New member
Ok I tested and this is why your write data and command didnt work...

this must be the order of these two signals

LCD_CS=0; // chip selected
LCD_RS=0; // set to write to the control registers

cannot be:

LCD_RS = 0; // set to write control registers
LCD_CS = 0; // chip selected

thanks the only thing keeping the lcd from working, just swap the order of those
 
But I do need " " around the source name or the project doesnt build.
That is bizarre, I think; I've never encountered that issue. When multiple source files are in the project, the linker takes care of resolving the data addresses. This makes me think it is behaving like some sort of "include". If the " " are removed, what is the error message for the build failure?
Taking the commas out of the end of the image files did not change anything.
What it would change is a compile error, unless you have those errors suppressed.
Code:
this must be the order of these two signals

LCD_CS=0; // chip selected
LCD_RS=0; // set to write to the control registers
cannot be:
LCD_RS = 0; // set to write control registers
LCD_CS = 0; // chip selected
I don't disbelieve you, but the timing diagram in the OTM2201 data sheet shows the RS signal preceeding the CS signal.

So, I presume everything is working now, and speed is satisfactory. Or do you still have a problem with the wrong image data?
There has got to be a way to clear the ram before each image.
You shouldn't need to clear ram unless you want a black area. Any image written should just overwrite what is in the location.
 
Top