Home
JAQForum Ver 20.06
Log In or Join  
Active Topics
Local Time 09:46 16 May 2024 Privacy Policy
Jump to

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 Kingdom
Posts: 8601
Posted: 11:23am 19 Jan 2015
Copy link to clipboard 
Print this post

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.
Edited by matherp 2015-01-20
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8601
Posted: 07:26am 20 Jan 2015
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2794
Posted: 08:23am 20 Jan 2015
Copy link to clipboard 
Print this post

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



Edited by WhiteWizzard 2015-01-21
For everything Micromite visit micromite.org

Direct Email: whitewizzard@micromite.o
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8601
Posted: 08:48am 20 Jan 2015
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2794
Posted: 09:16am 20 Jan 2015
Copy link to clipboard 
Print this post

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: Australia
Posts: 2870
Posted: 03:51pm 20 Jan 2015
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2794
Posted: 08:06pm 20 Jan 2015
Copy link to clipboard 
Print this post

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


Edited by WhiteWizzard 2015-01-22
For everything Micromite visit micromite.org

Direct Email: whitewizzard@micromite.o
 
matherp
Guru

Joined: 11/12/2012
Location: United Kingdom
Posts: 8601
Posted: 10:30pm 20 Jan 2015
Copy link to clipboard 
Print this post

  Quote  I assume there will be SPI versions of the 3.2" screen out there.


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: Australia
Posts: 2870
Posted: 11:15pm 20 Jan 2015
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 8601
Posted: 11:52pm 20 Jan 2015
Copy link to clipboard 
Print this post

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 Zealand
Posts: 9078
Posted: 09:47pm 27 Jan 2015
Copy link to clipboard 
Print this post

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 Kingdom
Posts: 2794
Posted: 09:56pm 27 Jan 2015
Copy link to clipboard 
Print this post

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 Zealand
Posts: 9078
Posted: 10:13pm 27 Jan 2015
Copy link to clipboard 
Print this post

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:

  matherp said  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.


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.Edited by Grogster 2015-01-29
Smoke makes things work. When the smoke gets out, it stops!
 
bigmik

Guru

Joined: 20/06/2011
Location: Australia
Posts: 2870
Posted: 10:19pm 27 Jan 2015
Copy link to clipboard 
Print this post

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

Edited by bigmik 2015-01-29
Mick's uMite Stuff can be found >>> HERE (Kindly hosted by Dontronics) <<<
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2794
Posted: 10:26pm 27 Jan 2015
Copy link to clipboard 
Print this post

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: Australia
Posts: 2870
Posted: 10:28pm 27 Jan 2015
Copy link to clipboard 
Print this post

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 Zealand
Posts: 9078
Posted: 10:30pm 27 Jan 2015
Copy link to clipboard 
Print this post

@ 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 Kingdom
Posts: 2794
Posted: 10:30pm 27 Jan 2015
Copy link to clipboard 
Print this post

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 Edited by WhiteWizzard 2015-01-29
For everything Micromite visit micromite.org

Direct Email: whitewizzard@micromite.o
 
WhiteWizzard
Guru

Joined: 05/04/2013
Location: United Kingdom
Posts: 2794
Posted: 10:33pm 27 Jan 2015
Copy link to clipboard 
Print this post

. . . . 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: Australia
Posts: 2870
Posted: 10:33pm 27 Jan 2015
Copy link to clipboard 
Print this post

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
© JAQ Software 2024