Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Some help on using a small 2.4" touch TFT display
387 views
Skip to first unread message
pozz
Mar 17, 2015, 7:24:41 PM3/17/15
to
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.
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.
Parallel MPU interface could save me an external SDRAM for framebuffer
(with parallel interface, the framebuffer is inside the external TFT
controlle) and simplify the PCB. I'm not able to understand if the
parallel bandwidth is sufficient for my application, but I'd like to
give it a try.
I have two questions related to drive the TFT module through parallel
interface.
The first: are emWin libraries released by NXP (and ST) compatible with
parallel interface? The original product (from Segger) is surely
compatible, but it's not clear to me if the compiled version released by
NXP (or ST) is compatible. I worry the compiler library could work only
with RGB interface.
The second question: should the MCU have an external memory bus for
interfacing the display? I know I can use a generic GPIO port as the
parallel port for the display, but I think the performance won't be
good. I think it should be better to interface the parallel port of TFT
to the external memory bus of the MCU.
In this case, I'm not sure how to make a good connection, how to manage
all the signals (chip select, write enable, read enable, ...). Do you
know any demo board with such kind of connection with publicly available
schematics?
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.
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.
Parallel MPU interface could save me an external SDRAM for framebuffer
(with parallel interface, the framebuffer is inside the external TFT
controlle) and simplify the PCB. I'm not able to understand if the
parallel bandwidth is sufficient for my application, but I'd like to
give it a try.
I have two questions related to drive the TFT module through parallel
interface.
The first: are emWin libraries released by NXP (and ST) compatible with
parallel interface? The original product (from Segger) is surely
compatible, but it's not clear to me if the compiled version released by
NXP (or ST) is compatible. I worry the compiler library could work only
with RGB interface.
The second question: should the MCU have an external memory bus for
interfacing the display? I know I can use a generic GPIO port as the
parallel port for the display, but I think the performance won't be
good. I think it should be better to interface the parallel port of TFT
to the external memory bus of the MCU.
In this case, I'm not sure how to make a good connection, how to manage
all the signals (chip select, write enable, read enable, ...). Do you
know any demo board with such kind of connection with publicly available
schematics?
rickman
Mar 18, 2015, 2:50:10 AM3/18/15
to
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
Michael Kellett
Mar 18, 2015, 5:04:04 AM3/18/15
to
pozz:
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
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
mmm
Mar 18, 2015, 6:22:16 AM3/18/15
to
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 ?
> 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.
>
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090
not sure for touch panel, but I am confident
<snip>
pozz
Mar 18, 2015, 8:28:04 AM3/18/15
to
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,
> 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.
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.
> 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.
possible.
pozz
Mar 18, 2015, 8:30:05 AM3/18/15
to
Il 18/03/2015 09:51, Michael Kellett ha scritto:
> 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.
I already know FT800 from FTDI, but it needs a RGB interface with the
> 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.
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.
pozz
Mar 18, 2015, 8:41:12 AM3/18/15
to
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 (www.saef.com.cn).
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.
edward....@gmail.com
Mar 18, 2015, 10:14:58 AM3/18/15
to
> 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 (www.saef.com.cn). 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.
rickman
Mar 18, 2015, 11:12:44 AM3/18/15
to
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
> 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.
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.
>> 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.
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
armCode
Mar 18, 2015, 11:23:53 AM3/18/15
to
>
>> The BOM list of that demo board reports a display from manufacturer
"xinc=
>> The BOM list of that demo board reports a display from manufacturer
>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
=
>
>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?
>
>
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
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Theo Markettos
Mar 18, 2015, 1:16:11 PM3/18/15
to
pozz <pozz...@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:
> 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.
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
lasselangwad...@gmail.com
Mar 18, 2015, 5:54:00 PM3/18/15
to
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
> 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.
>
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.
-Lasse
pozz
Mar 19, 2015, 4:00:55 AM3/19/15
to
Il 18/03/2015 18:16, Theo Markettos ha scritto:
> pozz <pozz...@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
> pozz <pozz...@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.
(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
but many LCD manufacturers have decided to cut this feature, bringing
out only the "MPU parallel" interface.
pozz
Mar 19, 2015, 4:07:13 AM3/19/15
to
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
> 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.
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.
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.
pozz
Mar 19, 2015, 4:09:55 AM3/19/15
to
Il 18/03/2015 22:53, lasselangwad...@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...
> 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
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
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.
pozz
Mar 19, 2015, 4:10:42 AM3/19/15
to
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.
> 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
pozz
Mar 19, 2015, 4:45:53 AM3/19/15
to
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
> interface (see page 20 and 21):
>
> http://embdev.ca/uploads/3/3/7/3/3373266/ut2.8cpi_usermanual-rev02.pdf
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)?
Robert Wessel
Mar 19, 2015, 5:54:36 AM3/19/15
to
On Thu, 19 Mar 2015 09:09:54 +0100, pozz <pozz...@gmail.com> wrote:
>Il 18/03/2015 22:53, lasselangwad...@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 -
>Il 18/03/2015 22:53, lasselangwad...@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.
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?
mmm
Mar 19, 2015, 8:18:42 AM3/19/15
to
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,
> 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).
>
the display looked VERY similar to el cheapo display available on ebay
and I didn't look at the schematics to confirm the interface
armCode
Mar 19, 2015, 8:47:50 AM3/19/15
to
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.
pozz
Mar 19, 2015, 1:07:08 PM3/19/15
to
Il 19/03/2015 13:47, armCode ha scritto:
>> 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:
So I did understand correctly. Thank you for sharing your code.
>> 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:
> 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.
Have you tried some graphical effects similar to the emWin sample "Smart
Phone Menu"
(https://www.segger.com/cms/admin/uploads/userfiles/file/emWin/samples/MOTION_SmartPhoneMenu.exe)?
Is the final effect acceptable?
And what about the transition from one screen to another one completely
different? Classic example: the user touches a button and goes to
another screen. Is the painting delay of the new screen noticeble?
armCode
Mar 19, 2015, 8:11:24 PM3/19/15
to
function is running every 10ms on a low priority task.
I have uploaded a video with some demo screens for the 8 bit MPU parallel
interface and 64K colors settings.There are custom fonts, significant
traffic over the Ethernet (MODBUS-TCP server) and a relatively large
application code running in background.
Note: Ignore the background LCD flickering. It is only present on recorded
video. I couldn't set my camera to record more than 30FPS.
http://youtu.be/XUyF-rui4m0
I hope this help ...
rickman
Mar 19, 2015, 10:33:11 PM3/19/15
to
On 3/19/2015 4:07 AM, pozz wrote:
> 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).
I don't know what your application is really. Your description is
> 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).
pretty vague, but if it is just menus it sounds pretty durn simple to
me. If you are using a CM3 or CM4 type processor with internal memory
your graphics will be constrained in many respects anyway due to the
limited memory size. Do a little math. How may pixels do you have?
How long does it take to write to the I/O port the LCD is connected to?
Do the math and see how long it takes to update it. You do know that
you can use I/Os that are on the same port so that a write is just a
very few processor cycles, right?
I expect your bottle neck will be generating the data to be displayed,
not the actual display writing.
I don't recommend that you ask for opinions. I don't know enough about
your project. For example you still haven't told me how many you plan
to make. I would bet you can find an existing product that will do
everything you need... unless there are things you haven't told us
about. Why reinvent the wheel? Are you planning to make millions of
them?
>>>> 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.
cost depending on your system. It all depends on things I don't know
about.
--
Rick
pozz
Mar 20, 2015, 3:44:29 AM3/20/15
to
Il 20/03/2015 01:11, armCode ha scritto:
> There is no noticeable delay between screens switching; the GUI_Exec()
> function is running every 10ms on a low priority task.
Are you using a RTOS? If yes, which one?
> There is no noticeable delay between screens switching; the GUI_Exec()
> function is running every 10ms on a low priority task.
> I have uploaded a video with some demo screens for the 8 bit MPU parallel
> interface and 64K colors settings.There are custom fonts, significant
> traffic over the Ethernet (MODBUS-TCP server) and a relatively large
> application code running in background.
>
> Note: Ignore the background LCD flickering. It is only present on recorded
> video. I couldn't set my camera to record more than 30FPS.
>
> http://youtu.be/XUyF-rui4m0
>
> I hope this help ...
The only "complex" graphic effect I'd like to implement is a smooth
scrolling list by touch (I've lists of 20-30 elements to show). Similar
to the "Smart Phone Menu" example of emWin.
Have you tried a similar thing?
I know it could be a long job to download, import and run the Smart
Phone Menu from emWin... anyway I ask you: could you make the test for
me and make a video? A beer for you :-)
armCode
Mar 20, 2015, 8:29:49 AM3/20/15
to
>Il 20/03/2015 01:11, armCode ha scritto:
>> There is no noticeable delay between screens switching; the GUI_Exec()
>> function is running every 10ms on a low priority task.
>
>Are you using a RTOS? If yes, which one?
>
I used Free RTOS and RTX. It really doesn't matter, all behave the same
>> There is no noticeable delay between screens switching; the GUI_Exec()
>> function is running every 10ms on a low priority task.
>
>Are you using a RTOS? If yes, which one?
>
way.
>
>> I have uploaded a video with some demo screens for the 8 bit MPU
parallel
>> interface and 64K colors settings.There are custom fonts, significant
>> traffic over the Ethernet (MODBUS-TCP server) and a relatively large
>> application code running in background.
>>
>> Note: Ignore the background LCD flickering. It is only present on
recorded
>> video. I couldn't set my camera to record more than 30FPS.
>>
>> http://youtu.be/XUyF-rui4m0
>>
>> I hope this help ...
>
>Great, this is very similar to my application and the result is very
good.
>
>
>The only "complex" graphic effect I'd like to implement is a smooth
>scrolling list by touch (I've lists of 20-30 elements to show). Similar
>to the "Smart Phone Menu" example of emWin.
>Have you tried a similar thing?
>
I didn't use the emWin's touch scrolling list but a smooth touch scrolling
>The only "complex" graphic effect I'd like to implement is a smooth
>scrolling list by touch (I've lists of 20-30 elements to show). Similar
>to the "Smart Phone Menu" example of emWin.
>Have you tried a similar thing?
>
list or list-wheel requires higher refresh rates. You won't get that
without an integrated controller and external display memory.
>I know it could be a long job to download, import and run the Smart
>Phone Menu from emWin... anyway I ask you: could you make the test for
>me and make a video? A beer for you :-)
>
>
pozz
Mar 23, 2015, 4:14:34 AM3/23/15
to
Il 20/03/2015 13:29, armCode ha scritto:
>> [...]
buttons to scrool long lists.
Just another question.
I see your board doesn't provide external non-volatile memory, such as
SPI Flash. In your application, the MCU internal Flash memory is
sufficient for graphics, fonts and so on? If I will need additional
memory for images and graphics, which one do you suggest?
>> [...]
>> The only "complex" graphic effect I'd like to implement is a smooth
>> scrolling list by touch (I've lists of 20-30 elements to show). Similar
>> to the "Smart Phone Menu" example of emWin.
>> Have you tried a similar thing?
>>
>
> I didn't use the emWin's touch scrolling list but a smooth touch scrolling
> list or list-wheel requires higher refresh rates. You won't get that
> without an integrated controller and external display memory.
I understand... it's a pity. I think I'll draw two simple up/down
>> scrolling list by touch (I've lists of 20-30 elements to show). Similar
>> to the "Smart Phone Menu" example of emWin.
>> Have you tried a similar thing?
>>
>
> I didn't use the emWin's touch scrolling list but a smooth touch scrolling
> list or list-wheel requires higher refresh rates. You won't get that
> without an integrated controller and external display memory.
buttons to scrool long lists.
Just another question.
I see your board doesn't provide external non-volatile memory, such as
SPI Flash. In your application, the MCU internal Flash memory is
sufficient for graphics, fonts and so on? If I will need additional
memory for images and graphics, which one do you suggest?
armCode
Mar 23, 2015, 9:54:41 AM3/23/15
to
For an external parallel FLASH you can use S29GL0xx with a LPC1788
micro-controller. You can try a SPI FLASH memory, but expect lower
performance.
Not sure about your complexity, but 512KB seems to be enough for the
applications I did so far. The app you have seen is around 200k code + 100k
read only data (no optimizations). It includes RTOS, TCP stack, emWin,
eight custom fonts, GUI menu, communication protocols, peripherals driver,
user code etc.
0 new messages