Grahic Driver Support
mynet43
Posts: 644
I'm writing a driver for a graphic LCD display that's 320x240 pixels. It uses the ILI9340 driver chip.
I've started with Rayman's driver and modified it to work with a 16 bit command and data structure (Ray's was 8 bit, using the ILI9325 chip).
I have it working well enough to initialize the display and fill it with any color I choose. So the basic command and data I/O seems to be working fine.
I'm now trying to get it to work with Chip's graphics routine. This isn't working quite right. I'm not outputting the screen data in the right order.
I'm calling the graphics routine with x_tiles = 20 and y_tiles = 15, so a 16x16 tile should give a 320x240 display.
Would someone please help me by describing the data structure generated by graphics.spin under these conditions? All I'm trying to do is figure out the order to output the data. I should be able to convert the 300 word (20x15 tiles) screen buffer to 76800 (320x240) 8-bit pixels. I think I'm doing this, but it's scrambled
Thank you for your help.
Jim
I've started with Rayman's driver and modified it to work with a 16 bit command and data structure (Ray's was 8 bit, using the ILI9325 chip).
I have it working well enough to initialize the display and fill it with any color I choose. So the basic command and data I/O seems to be working fine.
I'm now trying to get it to work with Chip's graphics routine. This isn't working quite right. I'm not outputting the screen data in the right order.
I'm calling the graphics routine with x_tiles = 20 and y_tiles = 15, so a 16x16 tile should give a 320x240 display.
Would someone please help me by describing the data structure generated by graphics.spin under these conditions? All I'm trying to do is figure out the order to output the data. I should be able to convert the 300 word (20x15 tiles) screen buffer to 76800 (320x240) 8-bit pixels. I think I'm doing this, but it's scrambled
Thank you for your help.
Jim
Comments
Apologies for bumping your thread without any specific information or experience with these driver chips other than reading through various datasheets.
I realize that you're seeking information on how to interpret the data structure of graphics.spin to resolve the scrambled results, but it's probably a good idea to continue checking the ILI9340 code, just in case.
For example, you might be doing everything right with respect to Chip's code and your interpretation thereof but think that you're not due to the scrambling. Filling the screen with just a solid color might be happening in a different order than you think, and the display driver might have ignored some received commands that you believe to be working due to the seemingly sucessful confirmation of the solid color result (you know, as long as the display memory is being plastered with the same color data). Perhaps you could try just filling just part of the screen area to see what happens. For potentially related info, skip ahead below.
I was actually unaware of the ILI9340 chip until you mentioned it. I occassionally visit Illitek's site (both .com and .com.tw) but they don't mention it. As far as I know, it's been a very long time since they've added a chip to those sites, so much so, that I was wondering if they'd merged with another company or something. But it seems that they just received a big touch screen controller order from Amazon, so, apparently, they're skipping right along. I had wondered why they didn't list, for example, an 800x480 driver (such as Solomon Systech's SSD1963), but, after just having done a search, they appear to have several other chips that I didn't know about (numbered higher than the ILI9325/40, but I haven't checked the details as to interface and memory, etc., so I might be mistaken). Still, I haven't seen those listed on their site (maybe I'm on an old site or need to refresh somehow). On the other hand, it seems that some companies don't want to be bothered with the "general public" knowing about their wares (for example, I've found it hard to get datasheets or product info for Novatek's wares).
So in Googling this as a result of your post (and coming across your Parallax thread at about 220 hits), I came across the following links which may or may not be of help (and which you have likely already seen, but fwiw):
[1] http://www.microchip.com/forums/m591480-print.aspx
[2] http://www.newhavendisplay.com/forum/viewtopic.php?f=6&t=1584
[3] http://forum.displaytech-us.com/2011/08/19/ili9340-solid-color-screen-sample-code-using-an-at/
For the first link above referring to a NewHaven display, the poster says, "The commands and their data are 8 bits, and I had the 16bit value (based on the driver code ili9320 (drvTFT001.c)) where I had my base. The data display is the same in 16bit. ... The colors, the startup code the value of gamma settings are written bad (is 8bit data at a time, and not 16bit). And yes the value RGB/ BGR is also wrong." So, you might want to check the format that you're using to send commands and also the RGB/BGR order.
The poster of the second link above says, "The ILI9340 works in the 8 bit mode with 8 bit commands and 8 bit parameters. This is contrary to the predecessor where all commands and paramters had to be 16 bit.
The data transfer to RAM is of course still 16 bits and is sent in 2 bytes with the Least significant byte first.
Another difference with the ILI 9328 is the setting of the row and page resgisters. They require now 4 parameters, the start adress (MSB, then LSB(2 bytes) and the end address(again MSB - LSB). If you send the RwGram command and then the RAM data, these data will only fill the pixels between start end end address." So, again, perhaps check that your commands are all 8-bit (you mentioned 16-bit).
The third link is just for reference or for comparson with the way you're setting up the ILI9340.
Anyway, obviously, you're doing something (if not everything) right in being able to "light up" the display with any color you like, but there still might be some "gotcha" hiding in there somewhere.
As far as the graphics.spin data structure interpretation, hopefully someone can chime in there with ideas to help you resolve matters if that's where the problem is or at least confirm your understanding (your thread had quickly fallen off the first page and might have missed some eyes). By the way, on a very quick inspection, I'm guessing this chip defaults to portait mode without commands to the contrary. Keep at it; people usually seem to resolve these display controller problems. Sometimes, just one piece of info on a datasheet can be in error (or correct data overlooked). Hope this bump helps and I wish you luck. --Jim
Thanks for the feedback, I appreciate it. Actually I think I've figured out most of the issues.
I started out with Rayman's driver for the ILI9325. He was using the 8-bit mode. I've been working with Newhaven Display, the maker of the display I'm using. The code example they have uses the 16 bit mode. So I decided to switch my code to 16 bit instructions and data.
I'm pretty sure I've figured out Chip's data structure. It helped a lot when I figured out it was in tiles rather than scan lines.
The initialization sequence and commands for the ILI9340 are entirely different from the ILI9325, so I had to
rewrite all of this. I've set the display to landscape mode, so I can fill the screen directly instead of transposing the data from portrait to landscape as in Rayman's code. It took me a while to figure this out.
I'm still having trouble with one screen command that sets the tile start and end addresses. Hopefully when I get this working I'll see some nice graphics. When I get it working I'll put it in the OBEX.
FYI, all of the display chip datasheets and sample code are available on the Newhaven web site. They have a bunch of them.
Thanks again for the help.
Jim
You can simply make Chips code run without the graphics buffer. The functions for line-drawing and so on can directly write the pixels into the display RAM. So, no tiles are involved.
You said you have a function running which sets a pixel. That's all you need for all the drawing functions. You can have a look at the driver I posted in you other thread. I also extracted the line-drawing from Chips code and made it use my version of the set-pixel. Maybe study of that code will help you to understand.
Thanks for all the suggestions and help.
I got it working, perfectly!
It does use the TILES and writes them as 16x16 pixel blocks on the screen. It seems reasonably fast and moves the graphics smoothly.
Thanks to Rayman for contributing the basic driver. It was an inspiration. I ended up making massive changes to it. The two chips, ILI9325 and ILI9340 are really very different, and I used the 16 bit commands and data I/O.
You can buy these displays at Digi-Key for $19. They're 320x240 full color displays.
Let me know if anyone would like a preliminary copy of the driver.
Thanks again for the help and suggestions.
Jim
I just found this thread after posting my own findings http://forums.parallax.com/showthread.php?135162-Displays-falling-in-price on the forum and then doing an external google search of the propeller forum.
I'd be very interested to see your code. In particular, your experience with using 16 bit commands as I can see these would be faster. How long does it take to do a screen refresh?
I'm thinking of the best way to interface these to a prop. Using the Arduino board? Or a new design that uses the full 16 bits and shares those bits with an external ram chip for things like fast C programs. I note your price at Digikey - that price is now cheaper than a similar sized TV screen for the propeller, and it would be nearly 4x the pixels and much much better resolution.
I'm reading the datasheet now http://www.displayfuture.com/engineering/specs/controller/ILI9320.pdf which is one of the chips in this family, though I note your comments about two of the chips being very different. I wonder which is the best one to choose?
Quick search on ebay for best price - $17 including shipping for display plus touchscreen plus standard dual header (easy to solder). ILI9325 driver chip.
I haven't timed the refresh rate but it's fine for my needs. It's all in assembly code. I'm using direct lines from the Prop for the interface. I'm also directly controlling the four LED backlights, so I can experiment with saving power. I'm using it on a battery powered device.
I'll be happy to supply you with my schematic if you're interested. It's for a very simple device that needs a nice display. I'm using all of the available Prop pins.
I tried two different versions of the display. I ended up using the NHD-2.4-240320SF-CTXI#-F1 because it connects to a socket on my board rather than having to be soldered directly to the board.
I can also supply you with the Driver Code. However, since I started with Rayman's code, he has asked that I not put it in the OBEX. It ended up being very different from his, but I respect his wishes.
You mentioned the ILI9320 and ILI9325 driver chips. My driver is based on the ILI9340 chip, which has a different command structure. Annoying
If you would like these, send me a PM with your email address and I'll attach them. The schematic and board layout are in DipTrace format. I can send you these or PDF files if you prefer.
By the way, where did you find the display on eBay?
Regards,
Jim
Re the boards on ebay, they are a bit hard to find as you get so many hits when you type in "display". What seems to find quite a few is a search for "2.8 display" and then as a separate search, "3.2 display" as these are two common sizes.
There are a few different driver chips so one has to choose one with the correct chip! Hence I am very interested in your comment about big differences.
The other thing is the plugs. There are those flexible ribbon connectors that look hard to solder. But some have a very standard looking 20x2 header. And there is the one with the arduino footprint too. I'm not sure but the Arduino one might be SPI, and I saw a youtube video of one of these where someone has posted a comment along the lines of - this is much slower than my display. So I suspect SPI is not going to be as rewarding as 8 bit or 16 bit parallel.
So in searching for displays, I think I'll narrow the search to only ones with the 20x2 header, as that can be plugged in and out of boards. And then narrow it down by both display size and by the driver chip. Many of these ebay ones are free shipping which compares favourably with digikey etc.
I'll send you the relevant part of the schematic and the code. Let me know if you need more info.
As far as the command differences, the original driver (Rayman's) was written for the ILI9325, using 8-bit commands. The display I'm using has the ILI9340 chip set. There are several complications here. When I started comparing the data sheets (very long and complex) I discovered that there were different commands for each chip. Some were the same, some were similar and some were totally different.
One of the biggest problems is the chip initialization code sequence. It's long and totally different in the two chips. In order to solve this, I was able to obtain C language sample code from Newhaven Display. They showed a sample initialization sequence, but used the 16-bit command codes. To make life easier, I decided to use the 16 bit codes, instead of Ray's 8 bit codes.
In order to get a landscape screen, Ray's driver outputs the data in portrait mode but translates the coordinates. After I figured this out, I decided to simplify it a little and output directly in landscape mode by using a landscape command to the display. All of this required major revisions to both the spin initialization code and the driver assembly code.
So now we have two entirely different display drivers. Ray's, which is great for the ILI9325 chip. And mine, which is coded for the ILI9340 chip using 16-bit commands and data transfer. Coding drivers like this is not for the faint of heart.
I use this driver only in the UpdateLCD mode, where you use Chip's Graphics.spin routines to fill the display buffer, then call the update routine to transfer the data to the display screen. This seems to work fine. It gives you everything you need. Variable font sizes, lines, circles, arcs, etc. Let me know if you have any questions. Suggestions or corrections are always welcome.
Regarding the connector. I'm using a SMT connector that mounts on the board and allows the display to be easily connected. I'll give you the P/N if you need it.
Let me know what you think.
Jim
would you be willing to share your work with me? I am interested in getting a touch-screen device up and running, and this looks like a good starting place for me. Please, PM me, or drop schematics/code somewhere where I can take a peek at what you ahve been up to with this one.
I am working on a display module from Displaytech (sdt024btft), and I have some drivers that were written for the ILI9320 and was trying to convert the drivers to work with ILI9340. Would you be willing to share your driver for the ILI9340, so that I could use it for my application.
Thanks much,
Jake
I'm happy to send you the code. Just send me your email address.
Please don't put it in the OBEX, per Rayman's request.
Talk to you soon.
Jim
It seems you have done a great job.
My e-mail is accessible for forum's members, but if there is a problem I'll send it to you on PM
Regards,
bkulev
I've jus bought the mentioned LCD & I'm attending to use it in a very smart small PDA I'm going to implement it, that can connect to WiFi & GPRS & GPS to do some certain things, but I'm facing some troubles with interfacing this LCD, & after a while of searching I found this post so I was wondering if you can share your code with me so I can try to extract what I'm not be able to creat, & my email is: steelth_2002 at hotmail dot com, I'll really appreciate your help & if you need any help with my device after I finish it I'll send you it's documents
Best Regards,
Ahmed
I just sent the driver to you. Please do not put it in the OBEX.
Let me know if you have any questions.
Jim
I just spotted this in an earlier post.
Having just written a program to rotate fonts 90 degrees, I see there are instructions in the display driver that change the mode from portrait to landscape. And then I found this post.
I guess I need to RTFM *grin*.
Thanks so much Jim & if there's anything I'll let you know
Best Regards,
Ahmed
Best Regards,
Ahmed
I believe I sent you three spin files. The Demo, the Graphics Driver and FullDuplexSerialPlus.
Besides these you will also need 'graphics.spin'. I will try to attach that here.
To run these you need to:
1. Copy all four files into a folder on your PC.
2. Attach the graphic display to your Propeller. (See 'GraphicCircuit.pdf')
3. Attach the Prop Plug between your PC and your board.
4. Turn on the power.
5. Load the Demo spin program into the Propeller IDE.
6. Press F11 to compile and load the firmware onto the Propeller.
7. You should see a display like that shown in 'Graphic Display.jpg'.
Please let me know if you have any questions.
Regards,
Jim
If you look at my code, I believe there is a routine called InitLCD.
There is a command WriteReg($36,$00A8) near the top of the routine.
I believe this command does a Row/Column exchange, which puts it in Landscape mode.
Let me know if you have more questions.
Have fun...
Jim