>Il 20/03/2015 13:29, armCode ha scritto:
> >> [...]
>>> 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
>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 board is built around LPC1768, no external memory controller.
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.
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Reply by pozz●March 23, 20152015-03-23
Il 20/03/2015 13:29, armCode ha scritto:
>> [...]
>> 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
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?
Reply by armCode●March 20, 20152015-03-20
>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
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
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 :-)
>
>
> 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 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 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 :-)
Reply by rickman●March 19, 20152015-03-19
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
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.
Yes, more hardware, but quick development and potentially a lower system
cost depending on your system. It all depends on things I don't know
about.
--
Rick
Reply by armCode●March 19, 20152015-03-19
>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):
>>>>
>>>>
>>>
>>> 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.
>
>
>> 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.
>
>Ok, I'll check.
>
>
>> 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
> 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?
>
>
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 ...
---------------------------------------
Posted through http://www.EmbeddedRelated.com
Reply by pozz●March 19, 20152015-03-19
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.
> 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.
Ok, I'll check.
> 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.
Good, because my application is similar to yours.
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?
Reply by armCode●March 19, 20152015-03-19
>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
Reply by mmm●March 19, 20152015-03-19
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
Reply by Robert Wessel●March 19, 20152015-03-19
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?