Lcd control
I have been going over the Ilitek data sheet again. I noticed that the I80 bus interface timing diagrams on page 66 of the manual and the diagrams on page 126 of the manual are not even close. Do you have any idea which diagram is correct? If it is the diagram on page 126 do you have a multiple byte operation to show how the lines should be driven? I am using the timing from page 66 right now. Is this the problem that I am having? The diagram on page 126 uses The nCS line as a strobe, not a select as is the case on the diagrams on page 66.
Any updates on this? I have hardware coming in a few days and this is now going to be a high priority for me.
James.
James,
I got the following from microchip. This could help you if you are using the microchip graphics library.
>>>>>>>>>>>>>>>>
DRIVER
<<<<<<<<<<<<<<<<<<<<
SSD1289.h/SSD1289.c
driver is more close to ILI9326.
1. Please
download the latest graphics library from www.microchip.com/graphics
2. In SSD1289.h
modify SetIndex() macro
/*********************************************************************
* Macros:
SetIndex(index)
********************************************************************/
#ifdef
USE_16BIT_PMP
#define
SetIndex(index) RS_LAT_BIT=0;PMDIN1=(WORD)index;PMPWaitBusy();RS_LAT_BIT=1;
#else
#define
SetIndex(index)
RS_LAT_BIT=0;PMDIN1=((WORD_VAL)(WORD)index).v[1];PMPWaitBusy();PMDIN1=((WORD_VAL)(WORD)index).v[0];PMPWaitBusy();RS_LAT_BIT=1;
#endif
3. In SSD1289.h
modify SetAddress() macro
/*********************************************************************
* Macros:
SetAddress(x,y)
********************************************************************/
#if
(DISP_ORIENTATION == 0)
#define
SetAddress(x, y) \
SetIndex(0x0210);WriteData(x);\
SetIndex(0x0212);WriteData(y);\
SetIndex(0x202);
#elif
(DISP_ORIENTATION == 90)
#define
SetAddress(y, x) \
SetIndex(0x0210);WriteData(x);\
SetIndex(0x0212);WriteData(y);\
SetIndex(0x202);
#endif
4. Request the ILI9326
initial code for this glass from the glass manufacturer.
5. In SSD1289.c
replace initial code in the ResetDevice() function with the code for your glass
(bunch of SetReg() calls)
6. Verify that in
the initial code you have:
SetReg(0x0211,0x00EF);
SetReg(0x0213,0x01AF);
I loaded the new microchip graphics library, and my little test bed for the display ceased to compile. I then copied it over to the new stuff, and I can't even get the display to blink now. I have verified that all of the signal lines look like I think they should be.
Is it possible to return the display to the factory so they can test it and tell me if it still works?
Stephan.
Hello everyone,
Some progress. I have the LCD powered and the backlighting working reasonably well. The display appears to be alive in that I can see data but it's all garbled and funny colours.
So I'm questioning the startup code since I understand it the least. Code samples below are taken from the application note that lists the startup code required.
First, can someone tell me what the macros or functions below do:
WMLCDCOM(0x0007);WMLCDDATA(0x0173);
I'm assuming this is writing the data 0x0173 to the register at address 0x0007. Is this correct?
Secondly, the last line is different than all the others:
WMLCDCOM(0x0202); // Write Data to GRAM
What is this supposed to do?
James.
James,
Look at page 66 of the ili9326 manual for the needed wave forms for the two macro's. WMLCDCOM should drive the RS line low when it does its transfer, This sets up the internal address pointer for the next operation. WMLCDDATA writes the data to the display with the RS line high. The WMLCDCOM(0x0202) sets the internal pointer to the GRAM address. This is shown in the diagram on page 103.
I am using the 8 bit interface. My problem is that I can not seem to get the GRAM pointer to point to anything besides 0,0.
Hope this helps.
Stephan.
Stephan et al,
So I've made some progress. I've confirmed that I can read out the ID register and a few others. So my data connection seems good and RS is toggling and read and write strobes are working.
I do get pixels to turn on but it doesn't look like what I expect.
On power up the display is white (it might be grey but it is solid). After the init routine (as per the application note) and the background changes to have alternating bright and dark lines. That doesn't seem right.
So it appears something in that init sequence isn't correct.
James.
OK, some more info.
I can draw a single pixel at some locations and in different colours. So I'm almost there.
I can set the one dimension but the other always starts at 0. Here's some code:
for( temp=422; temp<432; temp++ )
{
// write pixel (1, 1)
CS_LAT_BIT = 0;
SetIndex(0x0210); // sets RS LOW to start
WriteData(239);
SetIndex(0x0212); // sets RS LOW to start
WriteData(temp);
SetIndex(0x202); // sets RS LOW to start
WriteData( WHITE );
CS_LAT_BIT = 1;
Nop();
} // for temp
No matter what the starting point of temp is in the for loop, the line this draws always starts at the first column. The other dimension draws where I expect it.
I think I can conclude that all the connections are good and there isn't anything shorting. So it would seem that there is an issue in the init sequence or I have something not obvious messed up (which is a good possibility).
Cheers,
James.
OK, I've confirmed that I can read to general registers and read back and that I can read and write each bit (i.e. no shorts on data). So I'm pretty confident that my data interface is correct. It's also running quite a bit slower than I intend in the end, just to give some more margin (frequency is half what it will be and extra wait states added as well).
I can turn on a few pixels but not under proper control. It appears that the problem has to do with the GRAM address not being set correctly.
I'm using the 8-bit i80 interface and for now, for every pixel I do the following, (might have x and y reversed):
write x location
write register address 0x210
Jim,
I just had a minor breakthrough. I noticed that the value from the ap note for register 3 was 0x1098.
This did not make sense to me, so I changed it to 0x1030. I can now draw lines, but the display addresses go from top to bottom, right to left. I think that if I change the ID bits I should be able to get the display to go left to right. I used the following code fragment to write a diagonal line.
SetColor(YELLOW);
for( debug=10; debug<200; debug++ )
{
// write pixel (1, 1)
SetIndex(0x0200); // sets RS LOW to start
WriteData(debug);
CS_LAT_BIT = 1;
strobe_delay();
SetIndex(0x0201); // sets RS LOW to start
WriteData(50);
CS_LAT_BIT = 1;
strobe_delay();
SetIndex(0x0202); // sets RS LOW to start
WriteData(_color);
CS_LAT_BIT = 1;
strobe_delay();
} //
The set color routine just stuffs a pixel color value into a memory location.
note that registers 210-211 212-213 are used to make a window into the GRAM, Not to move the GRAM pointer around.
Stephan.
Hi Stephan,
Thanks for the update. I was just chasing down the same thing. It appears we were having the same (frustrating) conversation with the Ilitek people. Would it be so hard for them to simply post some example code?
In any case, I have a blue line now as well. I need to get the orientation fixed up as well, but good news all around.
BTW, I am using the PMP. So same result with two different methods.
And good to know I wasn't the only one who found the documentation confusing.
James.
Still a few things to iron out. I can get Line() and Circle() to work mostly. But the Bar() function doesn't work. Looks like a similar issue as before where an address isn't being updated properly and the 10-pixel wide bar becomes a 1-pixel line.
Also, can you find anywhere in the Microchip Library where they expect (0,0) to be? In video that is typically top-left. But is Microchip referencing bottom-left? Can't find anything to tell me definitively.
Cheers,
James.
Jim,
I got a hold of our Microchip FAE before he headed out for the day. He thinks that 0,0 is the top left, but wasn't sure. He will get back to me when he hears back from the factory in Chandler. We should have an answer sometime today.
Stephan.
James,
My guy at Microchip says that 0,0 is at the top left corner. It can be changed via the display orientation defines. Right now I have visible text displayed on the module rotated 90 degrees from where it should be. I am running the GOLDEMO right now.
Stephan
James,
to get the graphics library text to display right I had to reverse the x axis. With the display mounted with the connectors on the left side, 0,0 is on the top left. I am using the value 0x1038 for the entry mode register value (location 3).
This is my put pixel routine.
void PutPixel(SHORT x, SHORT y){
DWORD_VAL address;
SHORT new_x;
if(_clipRgn){
if(x<_clipLeft)
return;
if(x>_clipRight)
return;
if(y<_clipTop)
return;
if(y>_clipBottom)
return;
}
new_x = GetMaxX() - x;
SetAddress(new_x, y);
WriteData(_color);
CS_LAT_BIT = 1;
}
Hope this helps,
Stephan
James,
to get the graphics library text to display right I had to reverse the x axis. With the display mounted with the connectors on the left side, 0,0 is on the top left. I am using the value 0x1038 for the entry mode register value (location 3).
Are you trying to view in landscape or portrait? And when you say connectors, you mean side that the main and flex cable exit?
James.
I am using landscape format, and the connections are the flex cables.
I still have a problem where the display will only initialize the right 1/3. It worked fine until I came in this morning and is doing the 1/3 after the init. Seems to be some form of timing? I have been able to get the display to totally lock up also after a powerup. The only way to reset it seems to be a power cycle. We are going to fix this problem by placing a voltage regulator with an enable pin under processor control. We can then initialize the display, then read back some registers to see if it is working. If it doesn't respond, we can hit the power and then do the init again. When the display is working, the reset line works (clears what is on the display). When it is locked up it has no effect.
Stephan.
Having checked with my engineers, we noticed that the register 0x0003 (which is for the scan direction control) wasn't set, can you set this register and see if it works?
Hi Trevor,
Register 3 is set--see multiple posts above discussing what it should or shouldn't be. The DisplayTech code has one value uncommented and another one commented. It appears that the comments are reversed.
The point of contention seems to be that Microchip assumes top-left is (0,0) but there isn't really a mode that works well with that without doing some math to mirror the display. I'm working on finding all the places that need reversing--if it's not too many then that might be a solution.
James.
Hello Stephan,
Have you got the Bar() function to work? How about the button object? I can get Line(), Circle(), and text to display properly. But there is something about Bar() that still has the x index mirrored.
Have you modified Bar() at all?
James.
Hello Stephan,
I also had to modify Bar() that is used in many other objects. (It is also used to blank out the background of StaticText objects which is why I was seeing that not working--text was in the right place but it was blacking out the wrong area of the screen).
In any case, here is the updated Bar() along with the commented original lines. Initial clipping code isn't included here for brevity...
CS_LAT_BIT = 0;
for(y=top; y<bottom+1; y++){
// SetAddress(left, y);
// for(x=left; x<right+1; x++){
// WriteData(_color);
SetAddress((GetMaxX()-right), y);
for(x=left; x<right+1; x++){
WriteData(_color);
}
}
CS_LAT_BIT = 1;
So that appears to be working well now. Thanks for your help.
James.