TFT Display Driver - PIC 18F4550

[ninoq]

I'm using a PIC 18F4550 to develop a driver for a TFT display - http://www.emartee.com/product/41969/TFT%202.4%22%20320
The code below is based on Reference Code (an Arduino sketch - see pg. 11 - 8 bit mode) provided on the above product page and on code in post#23 at: http://forums.parallax.com/showthread.php/110134-2.4-quot-320x240-TFT-Prop-based-display-module/page2.

I've been unable to elicit any response from the display. All I get is a blank white screen - the same as when I first powered it up.

I've double checked the connections between the PIC and the display and they appear to be in order. I've also consulted the ILI9325 datasheet but to no avail.

Any guidance/advice would be appreciated.

[ezflyr]

Hi,

You need to take some small steps first! Do you know for a fact that your PIC is actually running? Do you know for a fact that it's running at the correct speed? Every one of my projects has a power LED driven by an I/O pin. I flash this LED at startup to tell me that the PIC is running. During early program development I set the flash rate to be one second On, one second Off, to let me know the PIC is running at the intended speed.

That display is a 3.3V unit, and your PIC is a 5V device. Can you tell us how you are powering each device, and how you are connecting the PIC to the display? The datasheet states that you need to use voltage dividers on the display I/O pins if the PIC is powered at 5V. Do you have a schematic?

An easy way to overcome any interface problems would be to use the 'LF' version of your PIC and to power it at 3.3V.

John

[drolleman]

I have developed on a 320 x 240 on a 18f part and found that it was slow! I then moved to a 33f part and it improved. but still slow, now I use a 33ep part @70 and it's acceptable. I now have a 7" screen @640 x 480 and will use 2 ep parts to drive it we will see how it works. just imagine my video card has 3000 cores, so what chance does a single core have to drive video? it would be nice if microchip would produce a multi core mcu.

[drolleman]

1. put a lot of delays in starting out slow is ok.
2. scope your pins make sure the signals are getting through correctly.
3. voltage dividers will slow down response time.

[MikeP]

I have been working with a TFTLCD that uses the same controller ILI9325 in 8bit mode.

http://www.adafruit.com/products/335
Yes the one I am using is pricey but it does 3.3/5V and is easy to connect to proto board.

I like this one too:
http://imall.iteadstudio.com/display/im120419009.html

I have working code for PC and PIC18F4550 for any ILI9325 GLCD that uses 8bit mode that can print to screen and draw a rgb565 bitmap gets the data from PC over USB connection for above GLCD. I have been working on the bugs/code clean up before ready for release. Just some of the gfxlib draw functions have bugs but that doesn't effect the print text and the bitmap drawing.

It takes 400ms to a draw picmap from usb sent data. I think this is as fast as I can make it. The use of a the 8bit port and the speed of the PIC limits this. I am using fast io and all of portD.
It was worse before I switched to bulk transfers and I did some work with the PC code side to queue 64K of USB data then call the PC side bulk_write function and not call it for each 64 byte packet.

Now are you wanting to learn how to do this yourself or do you think you would find my code useful? I converted adafruit's ILI9325 driver code over to CCS C. I need to make sure that I do what they require for release before release the driver code. I think, I just need keep it GPL and give them credit. But if you want to look at it/use it I will do that and release it ASAP on my git hub


notes on your code:

Now is there a reason you can't wire up port D of the pic to the 8bit bus on the 40pin header? The way you are doing it is gonna be really slow. looking at the docs for your GLCD use all of port D from the pic to go to DB8-15 pins on the 40pin header of the GLCD. The D0-D8 pins on the 40pin header should be connected to ground.

Then you could just use output_d( VH ) then do a WR_STROBE for the high byte then again for the lo byte.

Try this you should be able to to read the read ID data even if the LCD init didnt go right. just make sure reset pin is RST_ACTIVE. The following code will require changes to your wiring. I use the #bit stuff as it is faster way of accessing pins. If working readID() should return 0x9325

[ninoq]

Following up on MikeP's post, I'm getting 0x9393 not 0x9325. It seems to me that I'm reading the first byte (0x93) twice and not getting the second byte which I assume is 0x25. If I omit the second read I get 0x9300. I've tried changing the ReadID function so that it does the write/read cycle twice but it didn't help. I also tried adding an extra "WR_STROBE".

I'd appreciate advice/comments.

[MikeP]

sorry I forgot something, I set port to all output in my glcd_init function.

Do a SET_TRIS_B( 0x00 );

somewhere in your main before calling readID.

I think the tris defaults to 0xFF which is inputs. This may not be the problem but its the first thing I see after look over my cut and pasted code from last post. Sorry about that.

[ninoq]

My main had a Set_Tris_B in it:

[MikeP]

Yes this could be a timing issue. I will think about that more if the following code for you doesn't work. I know this code that I am posting is working I just tested it 2 times once without commenting out the line resetILI932x(); and once with that line commented out like the post is. Try both ways.

Note the reply you get can be 0x9325 or 0x9328 they are the same for the most part.

In 8bit mode you must read the HiByte and LoByte
In 8bit mode you must write the HiByte and LoByte

write8(0x00);
WR_STROBE; // Extra strobe because high, low bytes are the same

The above writes the HiByte and Lobyte of a 16bit word. The glcd looks for 2 WR_STROBES that how it knows when to sample its data bus and the CD_COMMAND; starts and CD_DATA; ends the command write part. Since the write8 function already did output_d( 0x00 ) thats what the glcd sees when you do the WR_STROBE;. So it will read the above as 0x0000

[ninoq]

I tried the code both ways and the result was the same - "ICID: 9393".

I'm not sure what to do next - I've rechecked the wiring and it's in order. Perhaps I should approach the vendor and/or the manufacturer.

Advice/comments would be appreciated.

[MikeP]

I cant get the page for your GLCD to load to look at the info on it


It seems to be in 16bit mode, does it default to that mode? What I remember from the quick look I give it the other day you had to change one of the resistors to another set of pads for 8bit mode. I assumed that you already did that since you were reading it in 8bit mode with your code. Did you change any of that?

Because if you tied d0-d7 to ground like we talked about and writing 0x00 it would get the 0x0000 part but only be able to read the high byte which is 0x93. I would almost be willing to bet that if after the program we have been using ran if you take the wires off d0-d7 and looked at each of those pins for high or low with multimeter the binary pattern would equal 0x25.

Lets add a while loop so we know the pic will stay in a known state. while you measure the pins.

[ninoq]

I disconnected DB0-7 from ground and added "while(TRUE) {;}" at the end of main. The ID changed from 0x9393 to 0x0000. I tested DB0-7 with a logic probe and a multimeter. The logic probe was neutral for all of the pins and the multimeter gave about -0.7V for each pin.

Early on I did query the vendor on the default mode and was assured that the display I got was in 8 bit mode.

For clarification I'm directly supplying 3.3V to the display.

[MikeP]

Disconnect DB0-7 from ground when the pic gets to the while line not before.
You should still get the 0x9300 out of it. Then measure pins d0-d7.

You need to leave them connect to ground so the write it sees is 0x0000.

I can't get to the page for the info on your GLCD. You need to read it and check that they really did what they said they did for you. If I remember right they come defaulted to 16bit mode.

Just so we all know you are running the PIC at 3.3V also?
Is it a 18F4550?

[ninoq]

To confirm - I'm using a PIC18F4550 (40-Pin PDIP). Pins 11 & 32 are connected to +5V and pins 12 & 31 to ground. The display's LED-A pin is connected directly to +3.3V on the same breadboard power supply used for the PIC18F4550.

I left DB0-7 connected to ground and waited till I got ICID:9393 and then disconnected DB0-7 from ground. I checked pins DB0-7 with both a logic probe and multimeter and got the same as before: neutral(no connection?) and -0.8V on each of the 8 pins.

[MikeP]

Is that GLCD 5V safe? The PIC is outputting 5V to it.