 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : TFT color LCD via SPI and the MM
| Author | Message | ||||
boss Senior Member  Joined: 19/08/2011 Location: CanadaPosts: 268 |
Good morning, one of the major disadvantages of the MaxiMite is an absence of the color display. This can be easily solved without any additional hardware, just by using a 4-wire SPI and one pin for RESET. I found one on eBay 3.5" TFT LCD 320x240/262k color controlled by SSD2119 chip which allows SPI communication. Yes, it is slow beause the INTERPRETER is slow and SPI runs at only 500kHz, but the chip itself supports up to 15Mhz SPI clock. A larger display, such as 4.3", has a resolution of 480x272, which is close to Maximite VGA but uses a parallel 16bit interface. This can be easily done with two 595 chips and a few MM pins (WR,CS and RESET). The code is not included because it is still very rough and buggy, but if someone is interested, I can send it. I think that the final solution probably should be written in C, as MM Basic command, or as a Library. The SPI command has to be modified as well. BTW. price for TFT is starginf from $35. http://www.ebay.ca/itm/120784266134?_trksid=p5197.c0.m619 Regards boss |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
H2012-04-16_053811_LCD_TFT.zip Here is the requested code and source where I learned what to do. Again the code is not nice, don't blame me. I started just yesterday and there is a lot to do. But it is working. boss |
||||
jman Guru  Joined: 12/06/2011 Location: New ZealandPosts: 711 |
Hi Have you seen this post http://www.thebackshed.com/forum/forum_posts.asp?TID=3732&KW =I2C Thanks for the code John |
||||
| mookster1 Regular Member  Joined: 10/06/2011 Location: New ZealandPosts: 81 |
That is pretty awesome  There's nothing like that on local auction site trademe, which is a bit of a shame because I'd like to get hold of one of those screens! Maybe you could have another PIC32 on a separate board to the Maximite acting as an external graphics card, which you can issue easy-to-read commands over a high-speed serial link, say "DRAW (LINE(x1,y1)-LINE(x2,y2))&COLOUR=#C0C0FF" etc. It could also have the power to do 3D stuff (hey, there's 128KB of RAM to play with without an interpreter soaking up precious resources!) so could be really brilliant for games-related stuff.Capacitance is futile - roll on 2012! |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi Mooster1, try to make some calculations: if we take modest VGA mode 640x480 an RGB 565 we have to have at least 640x480x2(Byte)=614400 Bytes. And PIC32 has 128k. and PIC32 SPI speed is limited as well. Regards boss |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
Hi, I have to apologize because I did miss the point. The best solution for LCD TFT should be tweaked existing VGA video to the high speed SPI (~15 MHz) instead to generate VGA signal. And then we can use up to 800x600 8"-10" LCD module. Reagards boss |
||||
| mookster1 Regular Member Joined: 10/06/2011 Location: New ZealandPosts: 81 |
Nah, that's fine mate
I've been thinking about colour video for a while and have been thinking about having a separate processor acting as graphics controller to implement. As the screen you mentioned above uses SPI, does this mean that it has to be constantly sent data to keep the image on the screen (like VGA) or can it just accept the data and keep displaying the image on the screen until more data is sent? If this is the case then the Maximite can split the screen into parts and send the graphics data part by part. Then the external unit turns that into data for the screen, and once the screen gets all the data the image can be displayed. Like this, you could probably get by with a lot less memory being used although I'm not too sure how quick it will be frames-per-second wise. If you used VGA I can see where you're coming from: all that information is stored in a buffer for another subroutine to sequentially go through and generate pulses for, and if you can avoid having all of the image in RAM at once it could possibly work quite well. Also another thing too: is 800x600 on a screen that size overkill? You could happily get by with 640x480 and still have acceptable-resolution graphics. Oh, and if everything was on an external board in another PIC32 with custom firmware, you could probably use a faster SPI clock rate as well  Capacitance is futile - roll on 2012! |
||||
| boss Senior Member Joined: 19/08/2011 Location: CanadaPosts: 268 |
The chips are different from VGA because they can buffer up to 1250 kilobytes of video data. You don't need to refresh the screen 50-100 times/s like VGA does. Actually, your idea is realistic and even most 8bit uP can do this job. With PIC 32 dedicated for GRAPHICS you can easily reach much a higher resolution than 800x600. And communication between MM and GP could be easily done via SPI up to 15Mbit/sec. Great idea. If I have spare time, I can try it. Regards boss |
||||
 Print this page |
