Some help on using a small 2.4" touch TFT display

pozz <pozzugno@gmail.com> wrote:
> At first, I was thinking to use MCUs with integrated TFT controller that 
> would drive "directly" the display through RGB interface (vsync, hsync, 
> dotclock, red, green, blue).  The problem arrived when I started finding 
> a suitable display: it's very difficult to find a small 2.4" TFT with 
> RGB interface.  Most of them provide only a parallel 8/16-bits MPU 
> interface.
> 
> I think because, at small sizes, the parallel MPU interface is generally 
> sufficient for most applications, where the graphics aren't too complex. 
>   So the RGB interface isn't necessary.

Are you sure?  For instance this:
http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=68&No=892
uses an ILI9341 as controller.  That allows an RGB interface (RGB, sync,
dotclock) through the MPU pins, but also modes to write to internal graphics
RAM, set gamma, backlight etc.  Datasheet:
http://www.adafruit.com/datasheets/ILI9341.pdf

Theo

Den onsdag den 18. marts 2015 kl. 13.28.04 UTC+1 skrev pozz:
> Il 18/03/2015 07:50, rickman ha scritto:
> > I don't know of an eval board with "such kind of connection" if you mean
> > an external bus.  But your concerns about performance of GPIO all
> > depends on what you plan to do with the display.
> 
> It's a simple HMI: some graphic buttons, dynamic text, several screens, 
> and so on.  It is simple, but I'd like to have good quality.
> For example, I'd like to have text rendering with alpha channel and to 
> have fluent transitions between two screens.  I don't want to have a 
> slow screen drawing, where I can see the painting from top to bottom.
> 

some of the STM32s have a port compatible with the usual intel/motorola interface on LCD controllers, for example: https://youtu.be/32Q-PeT5H8c

and afaict many of the lcd controllers can be put into a bypass mode so 
you get RGB interface

> 
> > Perhaps you should think about a more integrated system rather than a
> > separate CPU and display?  I believe the BeagleBone has a display port
> > that you can use to drive an LCD which is already configured to work
> > with it.  Or the Raspberry Pi can do that I think.
> 
> No, I have to design my own board and keep the total cost as low as 
> possible.

hard to beat the price of a $30 android tablet

-Lasse

Il 18/03/2015 18:16, Theo Markettos ha scritto:
> pozz <pozzugno@gmail.com> wrote:
>> At first, I was thinking to use MCUs with integrated TFT controller that
>> would drive "directly" the display through RGB interface (vsync, hsync,
>> dotclock, red, green, blue).  The problem arrived when I started finding
>> a suitable display: it's very difficult to find a small 2.4" TFT with
>> RGB interface.  Most of them provide only a parallel 8/16-bits MPU
>> interface.
>>
>> I think because, at small sizes, the parallel MPU interface is generally
>> sufficient for most applications, where the graphics aren't too complex.
>>    So the RGB interface isn't necessary.
>
> Are you sure?  For instance this:
> http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=English&CategoryNo=68&No=892
> uses an ILI9341 as controller.

Here 
(http://www.terasic.com.tw/cgi-bin/page/archive_download.pl?Language=English&No=892&FID=527f33a451f2c9a404934446366f5342) 
you can find the user's manual.  As you can see, the display is driven 
by a "MPU parallel port", not RGB.


> That allows an RGB interface (RGB, sync,
> dotclock) through the MPU pins, but also modes to write to internal graphics
> RAM, set gamma, backlight etc.  Datasheet:
> http://www.adafruit.com/datasheets/ILI9341.pdf

I know ILI9341 (and many others controller) provides RGB interface too, 
but many LCD manufacturers have decided to cut this feature, bringing 
out only the "MPU parallel" interface.

Il 18/03/2015 16:12, rickman ha scritto:
> On 3/18/2015 8:28 AM, pozz wrote:
>> Il 18/03/2015 07:50, rickman ha scritto:
>>> I don't know of an eval board with "such kind of connection" if you mean
>>> an external bus.  But your concerns about performance of GPIO all
>>> depends on what you plan to do with the display.
>>
>> It's a simple HMI: some graphic buttons, dynamic text, several screens,
>> and so on.  It is simple, but I'd like to have good quality.
>> For example, I'd like to have text rendering with alpha channel and to
>> have fluent transitions between two screens.  I don't want to have a
>> slow screen drawing, where I can see the painting from top to bottom.
>
> I'm not asking how you feel.  I'm asking you to define "slow".  If you
> can't quantify your requirements you can't design to them.  If you are
> talking about a simple menu like user interface where pressing a button
> brings up some type of options on a screen for the user to press more
> buttons, I can't see that needing a lot of performance from nearly any
> graphics device.

So, in your opinion and from your knowledge, for this kind of 
applications, it is sufficient to drive the LCD with a "simple" 
8-/16-bits "MPU parallel" interface, maybe controlled by software GPIOs 
(i.e., without a real hardware external bus).


>>> Perhaps you should think about a more integrated system rather than a
>>> separate CPU and display?  I believe the BeagleBone has a display port
>>> that you can use to drive an LCD which is already configured to work
>>> with it.  Or the Raspberry Pi can do that I think.
>>
>> No, I have to design my own board and keep the total cost as low as
>> possible.
>
> As to cost, you will be hard pressed to build a CPU as cheaply as the
> rPi unless you are building millions.  Even if you are rolling your own
> PCB, there is nothing to say you can prototype with an existing board
> and use that design in your product.  Both the Beaglebone and the rPi
> are open in that regard.  In fact, you asked about eval boards... so
> they are eval boards.

The complexity of rPI and BeagleBone are much higher than Cortex-Mx MCUs 
and they usually come with BGA packages that I'd like to avoid.

Anyway Cortex-M3/M4 MCUs cost about 4USD and don't need an external RAM 
(if I use the external TFT controller that integrates the memory for the 
framebuffer).

rPI and BeagleBone are Cortex-Ax that needs external RAM and greater 
complexity.

Il 18/03/2015 22:53, lasselangwadtchristensen@gmail.com ha scritto:
> Den onsdag den 18. marts 2015 kl. 13.28.04 UTC+1 skrev pozz:
>> Il 18/03/2015 07:50, rickman ha scritto:
>>> I don't know of an eval board with "such kind of connection" if you mean
>>> an external bus.  But your concerns about performance of GPIO all
>>> depends on what you plan to do with the display.
>>
>> It's a simple HMI: some graphic buttons, dynamic text, several screens,
>> and so on.  It is simple, but I'd like to have good quality.
>> For example, I'd like to have text rendering with alpha channel and to
>> have fluent transitions between two screens.  I don't want to have a
>> slow screen drawing, where I can see the painting from top to bottom.
>>
>
> some of the STM32s have a port compatible with the usual intel/motorola interface on LCD controllers, for example: https://youtu.be/32Q-PeT5H8c

Interesting...


> and afaict many of the lcd controllers can be put into a bypass mode so
> you get RGB interface

I know, but on 2.4" size, the manufacturer often decides to cut the RGB 
interface feature.


>>> Perhaps you should think about a more integrated system rather than a
>>> separate CPU and display?  I believe the BeagleBone has a display port
>>> that you can use to drive an LCD which is already configured to work
>>> with it.  Or the Raspberry Pi can do that I think.
>>
>> No, I have to design my own board and keep the total cost as low as
>> possible.
>
> hard to beat the price of a $30 android tablet

Sure?

Cortex-M3 could have a price of 4USD. 2USD maximum for PCB and 5USD for 
LCD 2.4". Some other small and cheap components and you can reach 
maximum 20USD, with manufacturing cost.

Il 18/03/2015 16:23, armCode ha scritto:
> The emWin libraries released by NXP are compatible with the parallel
> interface. You need to modify the provided LCD driver example. GPIO mode is
> just fine if you do not have an external memory interface. In terms of
> bandwidth, you should be fine unless you need to run a VNC server. In this
> case, your system needs enough RAM (internal or external) for the screen
> buffer to have reasonable refresh rates on the VNC client.
>
> Here is a good schematic example for a ILI9431 using 8 bit parallel
> interface (see page 20 and 21):
>
> http://embdev.ca/uploads/3/3/7/3/3373266/ut2.8cpi_usermanual-rev02.pdf

Thank you for the link.

Il 18/03/2015 16:23, armCode ha scritto:
> Here is a good schematic example for a ILI9431 using 8 bit parallel
> interface (see page 20 and 21):
>
> http://embdev.ca/uploads/3/3/7/3/3373266/ut2.8cpi_usermanual-rev02.pdf

If I understand correctly, the data bus of LCD is connected to GPIOs of 
MCUs.  It isn't used an MCU with hardware external bus.

I couldn't find example projects on the website, so I can't check.  Have 
you an idea of the performance that can be reached on this kind of 
connection (8-bits parallel data bus managed totally by software)?

On Thu, 19 Mar 2015 09:09:54 +0100, pozz <pozzugno@gmail.com> wrote:

>Il 18/03/2015 22:53, lasselangwadtchristensen@gmail.com ha scritto:
>> Den onsdag den 18. marts 2015 kl. 13.28.04 UTC+1 skrev pozz:
>>> Il 18/03/2015 07:50, rickman ha scritto:
>>>> I don't know of an eval board with "such kind of connection" if you mean
>>>> an external bus.  But your concerns about performance of GPIO all
>>>> depends on what you plan to do with the display.
>>>
>>> It's a simple HMI: some graphic buttons, dynamic text, several screens,
>>> and so on.  It is simple, but I'd like to have good quality.
>>> For example, I'd like to have text rendering with alpha channel and to
>>> have fluent transitions between two screens.  I don't want to have a
>>> slow screen drawing, where I can see the painting from top to bottom.
>>>
>>
>> some of the STM32s have a port compatible with the usual intel/motorola interface on LCD controllers, for example: https://youtu.be/32Q-PeT5H8c
>
>Interesting...
>
>
>> and afaict many of the lcd controllers can be put into a bypass mode so
>> you get RGB interface
>
>I know, but on 2.4" size, the manufacturer often decides to cut the RGB 
>interface feature.


At the end of the day, you just have that many pixels to update -
76800 for the common 320x240 2.4-inch devices.  What are the timings
like for the port you're going to be using?  Is this really going to
be an issue?

pozz wrote:
> Il 18/03/2015 11:22, mmm ha scritto:
> 
>> pozz wrote:
>>
>>> I'm going to develop a project where a small 2.4" TFT display module
>>> with resistive touch panel will be used.
>>>
>>> I'd like to use free emWin libraries distributed from NXP or ST for
>>> their Cortex-M3/M4 MCUs.
>>
>>
>> are you aware of this ?
>>
>> http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090
>>
>> not sure for touch panel, but I am confident
> 
> 
> It's another demo board that uses a small 2.4" TFT module with RGB 
> interface.  The other one I know is MCB4350 from Keil (with NXP MCUs).
> 

my mistake, I am sorry,

the display looked VERY similar to el cheapo display available on ebay 
and I didn't look at the schematics to confirm the interface

>Il 18/03/2015 16:23, armCode ha scritto:
>> Here is a good schematic example for a ILI9431 using 8 bit parallel
>> interface (see page 20 and 21):
>>
>> http://embdev.ca/uploads/3/3/7/3/3373266/ut2.8cpi_usermanual-rev02.pdf
>
>If I understand correctly, the data bus of LCD is connected to GPIOs of 
>MCUs.  It isn't used an MCU with hardware external bus.
>
>I couldn't find example projects on the website, so I can't check.  Have 
>you an idea of the performance that can be reached on this kind of 
>connection (8-bits parallel data bus managed totally by software)?
>
>
>

In this particular case the LCD (ILI9431) is using a 8/9 bit parallel
interface, using MPU's GPIOs. emWin provide a parallel driver
implementation you should modify (LCD_X_8080_8.c). Here is the driver
header I used:

#define LCD_CLR_RESET()   	(LPC_GPIO1->FIOPIN &= ~(1ul << 25))						///<
P1.25
	#define LCD_SET_RESET()   	(LPC_GPIO1->FIOPIN |= (1ul << 25))
	#define LCD_CLR_A0()      	(LPC_GPIO1->FIOPIN &= ~(1ul << 26))						///<
P1.26
	#define LCD_SET_A0()      	(LPC_GPIO1->FIOPIN |= (1ul << 26))
	#define LCD_CLR_WR()      	(LPC_GPIO1->FIOPIN &= ~(1ul << 21))						///<
P1.21
	#define LCD_SET_WR()      	(LPC_GPIO1->FIOPIN |= (1ul << 21))
	#define LCD_CLR_RD()      	(LPC_GPIO1->FIOPIN &= ~(1ul << 28))						///<
P1.28
	#define LCD_SET_RD()      	(LPC_GPIO1->FIOPIN |= (1ul << 28))
	#define LCD_CLR_CS()      	(LPC_GPIO1->FIOPIN &= ~(1ul << 18))						///<
P1.18
	#define LCD_SET_CS()      	(LPC_GPIO1->FIOPIN |= (1ul << 18))

	#define LCD_DATA_IN       	LPC_GPIO0->FIOPIN										///< P0.15 to P0.22

	#define LCD_DATA_OUT      	LPC_GPIO0->FIOPIN										///< P0.15 to P0.22

	#define LCD_DATA_MASK()	  	(LPC_GPIO0->FIOMASK = 0xFF807FFF)	
	#define LCD_DATA_UNMASK()	(LPC_GPIO0->FIOMASK = 0x00)

	#define LCD_DATA_DIR_IN() 	(LPC_GPIO0->FIODIR &= 0xFF807FFF)
	#define LCD_DATA_DIR_OUT() 	(LPC_GPIO0->FIODIR |= ~0xFF807FFF)
	#define LCD_SET_DIR_IN()  	(LPC_GPIO2->FIOPIN &= ~(1ul << 8)	)					///<
P2.8 - 0 (uC <- LCD)
	#define LCD_SET_DIR_OUT() 	(LPC_GPIO2->FIOPIN |= (1ul << 8)	)					///<
P2.8 - 1 (uC -> LCD)  


In your design, you can chose between 8, 16 or 18 bits, but first check on
Segger's library about driver availability for the selected connection
type. For ILI9341, some configurations are not fully supported yet.

In terms of  performance, for an HMI I do not see any issues, everything is
smooth. I am using active tile based HMI screens and other regular
graphical objects. If you plan animations,  parallel MPU interface might
not be enough. You will find a lot of answers on Segger user manual. 

  

 	   
					
---------------------------------------		
Posted through http://www.EmbeddedRelated.com