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 : MM2: 3.2" Colour TFT Touchscreen
Page 1 of 3 | |||||
Author | Message | ||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
One more display driver for the library - the last for the moment. This 3.2" Colour TFT Display uses a very common driver chip for the bigger displays - the SSD1289; it also includes a proper SPI touchscreen controller - the TSC2046. The pinout is a "standard" 40 pin header. The problem with all of these larger displays is that they seem to be wired for 16-bit parallel data input + the control lines - a lot of pins! However, this is easy to get round using a couple of cheap 74HC595 8-bit serial-in, serial or parallel-out shift registers. Using these we can drive the display using standard SPI from the Micromite. This technique is applicable to any peripherals that need a lot of inputs. This code implements the SSD1289 control requirements but loads the data via the shift registers. I've attached the same three programs as for the ILI9341 SPI display: 2015-01-19_215112_SSD1289.zip T32bas.bas does a complete demo and test of the graphics and text drawing routines. T32calibrate.bas uses the graphics routines and the touch routines and displays the coordinates wherever the screen is touched. This allows you to note down the maximum and minimum coordinates of the display screen for use in calibrating touch applications. In my case the Y coordinates run backwards (On the ILI9341 display it was the X). T32touchdemo.bas is a demo painting program using the touch input and graphics routines. Touching just below the drawing area on the left side clears the screen. Touching one of the colour blocks at the top of the screen changes drawing colour. The coordinates from the calibrate routine are used to define the xmin, xmax, ymin and ymax parameters. The software scales the touch position to the screen coordinates to draw the trace including reversing the sense of the raw y-coordinate. I've also attached a zip file of the c-code: 2015-01-19_215524_TFT32.zip There are brief notes in the INIT routine explaining the wiring of the 74HC595 chips but it is pretty obvious from the datasheet - the data input chains from one chip into the other so 16 clock pulses loads up all 16 outputs, then the latch pin is pulsed to load the output buffers. The clock, reset and latch pins are paralleled. Both output enables are permanently tied to GND. If you want to play with this display and have problems with the wiring let me know. |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Spent time today wiring this display direct to a 44-pin Micromite in full parallel 16-bit databus mode. I've also optimised the Cfunctions more for this specific controller. The result is lightning fast updates. So if you want a cheap big screen with proper touch capability and very fast drawing, this one + a 44-pin micromite is definitely the way to go. Basic examples: 2015-01-20_172202_T32parallel.zip C-Code: 2015-01-20_172137_TFT32par.zip The pinout avoids i2c, and comm1 pins and uses SPI for the touch input. However, the 2046 has a proper chip select so can share SPI with other devices. 'Fixed Pins setpin 25,dout 'c0 - connect to D0 setpin 26,dout 'c1 - connect to D1 setpin 27,dout 'c2 - connect to D2 setpin 36,dout 'c3 - connect to D3 setpin 37,dout 'c4 - connect to D4 setpin 38,dout 'c5 - connect to D5 setpin 2 ,dout 'c6 - connect to D6 setpin 3 ,dout 'c7 - connect to D7 setpin 4 ,dout 'c8 - connect to D8 setpin 5 ,dout 'c9 - connect to D9 setpin 30,dout 'a2 - connect to D10 setpin 31,dout 'a3 - connect to D11 setpin 13,dout 'a7 - connect to D12 setpin 32,dout 'a8 - connect to D13 setpin 35,dout 'a9 - connect to D14 setpin 12,dout 'a10 - connect to D15 dim integer T32_WR=21 'b0 dim integer T32_CD=22 'b1 ' Connect RD to VCC ' Connect CS to GND ' Connect SPI CLOCK to T_CLK ' Connect SPI OUT to T_DIN ' Connect SPI IN to T_DO ' 'Flexible pins dim integer T_IRQ=10 'T_IRQ dim integer T_CS=11 'T_CS DIM integer Master_reset=15 ' connect to reset pin display |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
By any chance, do you have a suitable 3.2" display that I can buy from you so that I can try your latest code offering? I would order from fleabay but to be honest the slow-boat from China is too slow for my liking. If not, can you do a quick video to show it working . . . . Thanks WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Here is a video The bits where nothing is changing are pause statements. The processing all takes place as the screen updates. |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Now thats quick! Would you suggest having two MicroMites in a solution, one dealing with the main task, the other dealing with the display (connecting the two MicroMites via some form of link) OR do you think there is enough spare 'processing time' to deal with the main task as well as the display? Hope this makes sense to you . . . WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Gday WW, When Peter was trying to get my 2.4" display going I suggested that if he could free up the I2C pins then we could build a dedicated driver board for the display that accepted I2C commands to drive the display... I was about to start tracking one out when Peter came up with the SPI version which only uses a few IO pins (5 or 6 I think) including the Touch screen function. That blew the 2 mite option away in my opinion. No need for a dedicated board if its only a few wires. I assume there will be SPI versions of the 3.2" screen out there. Regards, Mick PS.. Is there no stopping Matherp? He will be driving 65" 3D 4k screens next.. Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Mick, I see your point but for me Its not so much about 'spare' pins, more about available/spare processing 'power' after all the screen calculations are done. I ordered a batch of 2.4" TFTs to try this all out on (the day before Peter released his 3.2" code ) - I am just too curious and I can't evaluate things until the goods from China turn up (scheduled for Valentines day!). As for the 65" 3D 4k screen software release - yeah, come on Peter; anytime next week will do For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
All of the bigger screens seem to use this 40 pin connector and work 16-bit parallel. I think there is scope to layout a board which can take both this connector and one for the 2.4" SPI screen - will need a 44-pin Micromite. The pinout is very specific, it uses port C pins 0-9, and then port A 2,3,7,8,9,10 to make up the 16-bit port. This is the optimum I could find leaving all important pins (i2c etc.) unused. There is lots of spare processing capacity as the processor is only used when writing to the screen. I don't think the second processor approach is needed. Also, the code is now smaller and I still hope Geoff will be able to do something more about storage of CFunctions in a later release. The next size up screens use the SSD1963 and MD050SD controllers and resolution goes up to 800x480. For these 16-bit parallel is essential to get reasonable refresh speeds. |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Peter, There are some 3.2" TFTs that they advertise for the RPi that they state are SPI See eBay Link although they are not cheap. I bought a 3.2" display that had a daghterboard (an Arm Cortex I think) that I think can be written to SPI and it was probably around $20.. I will see if I can find it. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 8601 |
Mick The controllers all support SPI, but the people who put the cheap carrier boards together configure them for 16-bit parallel. As far as I can see the control lines that set this are hidden under the display and it is not possible to re-configure them. I think for the 44-pin MM this isn't a problem as there are lots of pins (pity the underlying hardware doesn't include a full 16-bit port though). SPI speed on a 320x240 display is OK although the parallel version is about 2x faster, but on anything bigger it is going to be too slow, depending on application. Peter |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
I am about to design a PCB for this module, coupled to the 44-pin uM chip, seduced mainly by the video that matherp linked to in post #4. The TFT module would mount directly onto a uM carrier PCB, with the idea being that a generic controller code could be designed so that commands sent via I2C or serial, could then control the screen, and feedback from the TFT could be processed and sent back by way of I2C or serial. The uM essentially becomes a glorified screen and touch controller, and that would be it's main task. I favour serial, just cos of the fact that there are RXD and TXD buffers by default - can't remember if there are such buffers with I2C. Also, using COM1, we could have VERY fast serial control commands and touch responses if we ran at 230k baud.(not that this is really needed, as the 44-pin uM would do all the hard work, really.) Is this a PCB that people would want? I have ordered a couple of those TFT panels linked to by matherp in post #1, but I am still having a bit of trouble trying to decipher the code to drive the screen. God bless matherp's Cfunctions - he the master(and da man!) with these screen driving routines..... Smoke makes things work. When the smoke gets out, it stops! |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
Hi Grogs, Go for it; such a module would be useful (and gets one of my things off my 'to-do'list Recommend a single PCB with the TFT mounted as close as possible to the PCB to keep the resulting module as THIN as possible. Also keep it to within similar proportions with just four mounting holes accessible. COM should be good enough but why not SPI/I2C as well? WW (PS did you sort out your Skype?) For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
I2C fine, but the SPI is used by the touch side of the panel. I only see one SPI channel on the uM - even the 44's. ...unless I missed something, which would not be the first time... As to dimensions, I would like it to piggy-back DIRECTLY onto the TFT module PCB, using the same exact mounting holes. You would then mount both the TFT module AND the carrier uM board using the same four bolts, and spacers - that's the plan anyway. EDIT: From post #2: With that in mind, I guess that SPI control is also possible on the same bus then, but not sure it would jive in this context - the touch controller would need to grab the bus with the CS line while anyone is touching the screen, which would mean that incoming commands on the SPI line would be ignored until the user moves their finger away, would it not? On the Skype - I will try to get that fixed ASAP. I found my old Skype phone, but it is not compatible with Win8, so I will have to get a headset or a new Skype phone. Smoke makes things work. When the smoke gets out, it stops! |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Grogs, WW, Is it really going to be better with a piggy back board compared to the SPI driven module? Not a criticism just a question.. In both cases the main `mite will have to do maths for where it wants to draw boxes etc and then convert it to `commands' for the module to drive. It seems to me that the SPI module already fills the `slave' idea well, unless you wish to task the 44 pinner to the display AND have the left over I/O (still about 20 pins) available for other things.. then I can see your point. Also the touch functions on the parallel TFT screen are doubled up and not connected to their own controller, With the SPI screen the touch has a controller connected to the SPI bus.. Maybe MatherP wants to chip in here.. Dont get me wrong I like the idea, I see that the PCB would just slip over the square pins and be soldered directly to the TFT screen (no headers) for minimal depth increase.. Mick OOps!! Maybe I should read the Topic first.. I though you were talking about the cheapo 2.4" screens.. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
I couldn't keep up with matherp in remembering which display used which interface (which is why I put "SPI/I2C". I would steer clear of SPI for this particular TFT to keep down the potential 'conflicts'. I do understand Micks comments about needing a piggy-back-board - that is why I had asked the question about enough spare 'power & resource' left over in the PIC; or whether a second PIC is required. The benefit of a module with a 44-pinner is that it opens it up to other micro controllers. The RaspberryPi version of the 3.2" touch TFT retails in the UK for £49.99. This could retail for £15+ so would sell well! Anyway, it keeps Grogster busy and off the streets! My vote is yes - do it! WW For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
Grogs, WW, I would Vote Yes as well. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
Grogster Admin Group Joined: 31/12/2012 Location: New ZealandPosts: 9078 |
@ Mick - Heh heh, yeah. I looked at the 2.4" SPI ones, but as matherp says in the first post - bigger is better. And it is. My main thinking was to distil the commands down to nice simple things, so that people who want a touch screen on their project, don't have to learn a mountain of code on how to drive it. Using I2C or serial means that just about anything could drive it, and the user does not need to know MMBASIC or have to include complicated TFT and touch driver routines into their main code. The KISS approach in action, once again. Smoke makes things work. When the smoke gets out, it stops! |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
I wonder how matherp is getting on with his CFunctions for hooking the MicroMite to that 65" 16HD display? Guess thats why he's been a bit 'quiet' on here recently For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
WhiteWizzard Guru Joined: 05/04/2013 Location: United KingdomPosts: 2794 |
. . . . here is a link to a UK TFT touch module (it is only 2.8" too!) For everything Micromite visit micromite.org Direct Email: whitewizzard@micromite.o |
||||
bigmik Guru Joined: 20/06/2011 Location: AustraliaPosts: 2870 |
WW, I heard that MatherP has gone onto a 110" 16k pixel Oled screen, that uses pentodes to drive it. Mick Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<< |
||||
Page 1 of 3 |
Print this page |