Some help on using a small 2.4" touch TFT display

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.

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.

--

Rick

pozz:

that

hsync,

finding

generally

complex.

with

by

only

TFT

manage

available

Take a look at FTDI's FT800 chips and development packages - the FT800 offloads the display control and graphics library to an external chip (which is a bit different from using the NXP library but in some ways more portable). They sell development boards with little displays which might be good for small qunatity production but can be cloned for volume.

MK

are you aware of this ?

not sure for touch panel, but I am confident

Il 18/03/2015 07:50, rickman ha scritto:

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.

No, I have to design my own board and keep the total cost as low as possible.

Il 18/03/2015 09:51, Michael Kellett ha scritto:

I already know FT800 from FTDI, but it needs a RGB interface with the TFT display, but it's very difficult to find in small-sized display, such as 2.4".

Indeed their basic modules starts from 3.5" models.

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).

I don't know why they (ST and Keil) produce demo boards with displays that are very difficult to find on the market. Many TFT manufacturers I contacted don't have such displays in normal production programs. Of course, many are available to make a custom product, but I prefer to avoid this way.

The BOM list of that demo board reports a display from manufacturer "xinchuangtianyuan". I couldn't find it. The part number is SF-TC240T-9370-B-T and some google search says it is from Saef Technology Limited

On their website, the only 2.4" TFT module doesn't have RGB interface. Maybe they created a custom product for Discovery demo board for ST.

huangtianyuan". I couldn't find it. The part number is SF-TC240T-9370-B-T and some google search says it is from Saef Technology Limited (www.saef.c om.cn). On their website, the only 2.4" TFT module doesn't have RGB interf ace. Maybe they created a custom product for Discovery demo board for ST.

That's typical, even for standard interfaces. If ST paid for toolings for such product and they sell them to you without tooling costs. Would ST go back to them next time, other than with their lawyers?

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.

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.

--

Rick

"xinc=

SF-TC240T-9370-B-T=

(www.saef.c=

interf=

=

=

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):

--------------------------------------- Posted through

Are you sure? For instance this:

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:

Theo

Den onsdag den 18. marts 2015 kl. 13.28.04 UTC+1 skrev pozz:

some of the STM32s have a port compatible with the usual intel/motorola interface on LCD controllers, for example:

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

hard to beat the price of a $30 android tablet

-Lasse

Here

you can find the user's manual. As you can see, the display is driven by a "MPU parallel port", not RGB.

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.

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).

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, snipped-for-privacy@gmail.com ha scritto:

Interesting...

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

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:

Thank you for the link.

Il 18/03/2015 16:23, armCode ha scritto:

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)?

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?

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

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 FIOPIN |= (1ul FIOPIN &= ~(1ul FIOPIN |= (1ul FIOPIN &= ~(1ul FIOPIN |= (1ul FIOPIN &= ~(1ul FIOPIN |= (1ul FIOPIN &= ~(1ul FIOPIN |= (1ul 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