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.Another thing is that CF support said to "reset the RAM address at the end of each row"
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.Is there a way to instantly display the image and not have it run one pixel at a time...
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.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...
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
}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.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..
Data storage declaration in header files is not "wrong", it is just not standard practice. You can also #include .c files, too, ya know?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?
No big deal, since you have to make 2 writes per pixel anyway.I am stuck with the char size colors, 'cuz image2lcd.exe only prints it this way...
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;
}
}
}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
}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.So for some reason it is necessary to keep the RD, WR, RS extra commands in there.
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.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...
&[SIZE="6"]"[/SIZE]image01.c[SIZE="6"]"[/SIZE][0] 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]);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?But I do need " " around the source name or the project doesnt build.
What it would change is a compile error, unless you have those errors suppressed.Taking the commas out of the end of the image files did not change anything.
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 selectedYou shouldn't need to clear ram unless you want a black area. Any image written should just overwrite what is in the location.There has got to be a way to clear the ram before each image.