TFT Colour LCD controllers with SPI interface

andrewm1973

Level: Hangaround

Joined: Sat. Aug 21, 2004

Posts: 360 View posts

Location: down under

#52

Posted by andrewm1973: Wed. Apr 10, 2013 - 11:42 PM

treat

1..8 as 0..7

and

10..17 as 8..15

You'll be fine :)

andrewm1973

Level: Hangaround

Joined: Sat. Aug 21, 2004

Posts: 360 View posts

Location: down under

#53

Posted by andrewm1973: Wed. Apr 10, 2013 - 11:43 PM

BTW - I note pin 21 is listed as N/C as usual.

If you give some nice high res photos of both sides of the FPC (like >5 Mpixel and clear) we can work out what the hidden pins are.

valusoft

Level: Moderator

Joined: Sat. Jul 2, 2005

Posts: 15757 View posts

Location: Melbourne, Australia

#54

Posted by valusoft: Thu. Apr 11, 2013 - 12:39 AM

Please DO NOT attach a ">5 Mpixel" photo here. Some folks will be bankrupted by it! If you must ... provide a link to it so those who don't mind its size can examine it.

Cheers,

Ross

Ross McKenzie ValuSoft Melbourne Australia

Torby

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10380 View posts

Location: Bartlesville Oklahoma USA

#55

Posted by Torby: Thu. Apr 11, 2013 - 02:10 AM

Oh. Mystery solved. In 16 bit mode, you don't use DB0 or DB9.

If I make a big photo, I'll upload it somewhere, not attach it.

Attachment(s):

MysterySolved.png

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

Torby

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10380 View posts

Location: Bartlesville Oklahoma USA

#56

Posted by Torby: Thu. Apr 11, 2013 - 05:24 PM

Dave, I've pirated your thread. Sorry.

And don't order this one, it's not SPI, but it looks like I can use it.

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30662 View posts

Location: Wormshill, England

#57

Posted by david.prentice: Thu. Apr 11, 2013 - 08:46 PM

That is no problem. I got a ILI9320 running in SPI mode quite nicely. It is obviously slower than native 8-bit or 16-bit mode. However it is faster than some Arduino TFT 16-bit libraries!

I would never bother with 16-bit unless I was using a 16-bit (or 32-bit) chip. 8-bit only costs you a SBI,CBI sequence. --- 4 cycles.

Have you got everything working now?

David.

Torby

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10380 View posts

Location: Bartlesville Oklahoma USA

#58

Posted by Torby: Fri. Apr 12, 2013 - 01:29 AM

I layed out a board to connect my display to a Mega 1284. I arranged it for 16 bit. Now, I either etch one here and hand connect many jumpers on the bottom side, or send out. Laying it out was beyond my 1 sided home etching abilities. I included a connector for a NRF24L01, a power supply to run from 2 AA batteries and a boost converter to run the backlight LEDs.

Maybe I'll read again on 8 bit. Perhaps that will simplify the board enough I can make one here. That would also free up some pins on my 1284.

Wonder what it takes to use the touch sensor. It has X+, Y+, X- and Y- connections.

Pretty impressed with what 10 bucks got.

Attachment(s):

TFTTrainer.png

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

js

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 30146 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#59

Posted by js: Fri. Apr 12, 2013 - 01:37 AM

Quote:

Wonder what it takes to use the touch sensor. It has X+, Y+, X- and Y- connections.

Very little. Massage as required by your setup.

#define T_YU PE7	// Pin 37 can be a digital pin
#define T_XL PE6	// Pin 38 can be a digital pin
#define T_YD PF3	// Pin 39 must be an analog pin, use "An" notation!
#define T_XR PF2	// Pin 40 must be an analog pin, use "An" notation!
.
.
void readTouch(void) 
	{
	//Do X
	ADMUX=(1<<REFS0 | ADC_2);	//Conversion on channel 2, AVCC reference,
	PORTE |= (1<<T_YU);		// YU High (V+ YU)
	DDRE |= (1<<T_YU);		// YU output
	PORTF &= ~ (1<<T_YD);	// YD Low (gnd YD)
	DDRF |= (1<<T_YD);		// YD output
	PORTE &= ~ (1<<T_XL);	// XL low (no pull up)
	DDRE &= ~ (1<<T_XL);	// XL input (disconnected)
	PORTF &= ~ (1<<T_XR);	// XR low (no pull up)
	DDRF &= ~ (1<<T_XR);	// XR input (ADC 2 read)
	_delay_ms(1);
	ADCSRA |= (1<<ADSC);					//Start conversion
	loop_until_bit_is_clear (ADCSRA, ADSC);	//Wait for conversion complete
	p_x =  ADCW;

//Do Y
	ADMUX=(1<<REFS0 | ADC_3);	//Conversion on channel 3, AVCC reference,
	PORTE |= (1<<T_XL);		// XL High (V+ XL)
	DDRE |= (1<<T_XL);		// YU output
	PORTF &= ~ (1<<T_XR);	// XR Low (gnd XR)
	DDRF |= (1<<T_XR);		// XR output
	PORTE &= ~ (1<<T_YU);	// YU low (no pull up)
	DDRE &= ~ (1<<T_YU);	// YU input (disconnected)
	PORTF &= ~ (1<<T_YD);	// YD low (no pull up)
	DDRF &= ~ (1<<T_YD);	// YD input (ADC 3 read)
	_delay_ms(1);
	ADCSRA |= (1<<ADSC);					//Start conversion
	loop_until_bit_is_clear (ADCSRA, ADSC);	//Wait for conversion complete
	p_y =  ADCW;
}

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

Torby

Level: 10k+ Postman

Joined: Tue. Nov 11, 2003

Posts: 10380 View posts

Location: Bartlesville Oklahoma USA

#60

Posted by Torby: Fri. Apr 12, 2013 - 01:49 AM

Oh. So you just read it with the A/D. That's handy.

#define T_YU PE7   // Pin 37 can be a digital pin 
 #define T_XL PE6   // Pin 38 can be a digital pin 
 #define T_YD PF3   // Pin 39 must be an analog pin, use "An" notation! 
 #define T_XR PF2   // Pin 40 must be an analog pin, use "An" notation!

Can you interpret T_YU, T_XL, T_YD and T_XR for me? These are where you connected the Y+, X-, Y- and X+ lines?

If you don't know my whole story, keep your mouth shut.

If you know my whole story, you're an accomplice. Keep your mouth shut.

andrewm1973

Level: Hangaround

Joined: Sat. Aug 21, 2004

Posts: 360 View posts

Location: down under

#61

Posted by andrewm1973: Fri. Apr 12, 2013 - 02:30 AM

david.prentice wrote:

I would never bother with 16-bit unless I was using a 16-bit (or 32-bit) chip. 8-bit only costs you a SBI,CBI sequence. --- 4 cycles.

David, You are obv. not a lunatic like I am. I am chasing every clock-tick I can :D

I can now clear 320x240 pixels in 10mS and I can draw (diagonal) lines with Bresenham at an average of about 40 ticks per pixel.

js

Level: Moderator

Joined: Wed. Mar 28, 2001

Posts: 30146 View posts

Location: Sydney, Australia (Gum trees, Koalas and Kangaroos, No Edelweis, but plenty of Corona beer)

#62

Posted by js: Fri. Apr 12, 2013 - 02:50 AM

Quote:

These are where you connected the Y+, X-, Y- and X+ lines?

Correct, the touch panel becomes just 2 "pots" one vertical and the other horizontal.

You supply power to 2 legs and read the "wiper", then do the same for the other "pot".

By the way should we split the thread away from the original SPI version?

David may want to comment on this too.

John Samperi

Ampertronics Pty. Ltd.

https://www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30662 View posts

Location: Wormshill, England

#63

Posted by david.prentice: Fri. Apr 12, 2013 - 07:35 AM

Quote:

I can now clear 320x240 pixels in 10mS and I can draw (diagonal) lines with Bresenham at an average of about 40 ticks per pixel.

That IS impressive. I have the Adafruit library doing a fillscreen() in 52ms and drawing a diagonal line in 172us. - with a SST1289 8-bit on an UNO.

Mind you, I removed a fillscreen optimisation for some reason or other. I might put it back and see the difference.

David.

p.s. I removed the optimisation because it does not work with SPI. The theoretical best time for fillscreen() would be 9.6ms. You achieving 10ms is really good! The theoretical best with SPI is 76.8ms.

Anyway, I don't see fillscreen() as the most important benchmark. Blitting real data from a bitmap or JPEG is more useful test. After all, how useful is a uniformly coloured blank screen?

andrewm1973

Level: Hangaround

Joined: Sat. Aug 21, 2004

Posts: 360 View posts

Location: down under

#64

Posted by andrewm1973: Fri. Apr 12, 2013 - 08:49 AM

Quote:

Anyway, I don't see fillscreen() as the most important benchmark. Blitting real data from a bitmap or JPEG is more useful test. After all, how useful is a uniformly coloured blank screen?

Well - I am waiting for frame flyback, clearing the screen and then drawing a scene once every 1/30 of a second. So in my application that doesn't show JPGs clear screen is pretty important :D.

Quote:

That IS impressive. I have the Adafruit library doing a fillscreen() in 52ms and drawing a diagonal line in 172us. - with a SST1289 8-bit on an UNO.

Is 172uS a typo? A diagonal line across the screen (0,0,319,239) is 400 pixles long. That only works out at 7 clocks per pixel at 16Mhz.

Mine takes 692uS for a full diagonal line (avg 28 clocks/pixel) using Bresenham. I did experiment with run length line algos, but most of my lines are short and the DIV kills RLL. Even still I don't think I would get down to sub 7 clocks.

Edit: Oops that 692uS was with some other things happening. It's 608uS at 25clk/pixel. Still a long way from 7.

Ambroise_Leclerc

Level: Rookie

Joined: Sun. Jan 19, 2014

Posts: 39 View posts

#65

Posted by Ambroise_Leclerc: Wed. Apr 2, 2014 - 07:59 PM

I have tested three SPI solutions that seems to correspond to your problem.
The first one can be faster than parallel mode, and the 2 others are compatible with a restricted budget :

1) A $16.99 Sainsmart 3.2" 16-bit touch screen with a SSD1289 controller.

I have used a MCP23S17 I/O expander to provide a SPI connection with an atmega328.

There's a great benefit with the I/O expander : you don't have to send again the 16 bits of data when it remains the same.
For a fillscreen (or fill windows), you simply have to send the color data onece and then to toggle CS for each pixel.

An unoptimized fillscreen takes 9.6ms. And with a 30 levels loop unrolling optimization a fillscreen takes 5,2 ms.

2) A $14 Thaoyu Electronics 2.8" SPI touch screen (model HY28A LCDB)

It's based on a ILI9320 controller. Performance is low due to SPI limitations but yon can improve it by using your own SPI implementation.

Standard implementation relies on such a transfer function :

  /// Transfers one byte over the SPI bus and receives one byte from slave
  /// @param[in] data to send
  /// @return received data
  static uint8_t Transfer(uint8_t data)
  {
    DataRegister::Assign(data);
    while (!TransferCompleted()) {}
    return DataRegister::Get();
  }
  
  /// Tests if the last transfer is complete
  /// @return true if last transfer is complete
  static bool TransferCompleted()
  {
    return (StatusRegister::TestBits(1<<SPIF));
  }

Defining a simpler asynchronous function :

 /// Transfers one byte over the SPI bus without waiting for completion
  /// @param[in] data to send
  static void TransferAsync(uint8_t data)
  {
    DataRegister::Assign(data);
  }

gives a good opportunity to perform graphics computations during the SPI transfer completion.

3) A $6.99 EastRising 2.8" SPI LCD Module
This module is based on a ILI9341 controller.

It's a very affordable solution but with it's tiny FPC-connector, I had a lot of difficulties to connect it and to make it work reliably.

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30662 View posts

Location: Wormshill, England

#66

Posted by david.prentice: Wed. Apr 2, 2014 - 08:26 PM

The ILI9341 is a lovely controller. It handles rotation seamlessly.
With the ILI9320, ILI9325 you have to transform your X, Y coordinates in software.

Have you looked at the http://www.ebay.co.uk/itm/1PC-2-2-Inch-SPI-TFT-LCD-Serial-Port-Module-Display-ILI9341-5V-3-3V-New-/380708838265?pt=UK_BOI_Electrical_Components_Supplies_ET&hash=item58a403db79 modules?

Ok, there is no touchscreen but you get a SD Card socket.

As far as I can see, all makes of TFT controller have multiple interface types. However, you can't always get at the IM# configuration pins.

I can't see any point in using a SPI bus-expander when you could use native SPI on the controller in the first place !

But yes, you can do the "fillScreen" optimisation if you can provide the colour on a 16-bit parallel bus.

David.

Ambroise_Leclerc

Level: Rookie

Joined: Sun. Jan 19, 2014

Posts: 39 View posts

#67

Posted by Ambroise_Leclerc: Thu. Apr 3, 2014 - 06:24 PM

david.prentice wrote:

Have you looked at the ... modules?

Yes, I have one of these modules but I have paid twice your price !

david.prentice

Level: 10k+ Postman

Joined: Sat. Feb 12, 2005

Posts: 30662 View posts

Location: Wormshill, England

#68

Posted by david.prentice: Thu. Apr 3, 2014 - 06:33 PM

I have two of those modules. I paid more for the first one. (but not 2x)

David.

AVR Freaks