Easy embedded GUI

For a product I need a simple GUI, but it must be color en look "good". We intend to use a 2.4" - 3.5" MVA or IPS panel and those are available with RGB or processor interface, even SPI is possible. The application itself does not require a large processor. No touch screen, only a few buttons (2 - 4).

One option is to use an NXP LPC1800 with their free (but binary and fixed to NXP processors with integrated LCD controller) emWin library. Any experiences with that? How long to get a GUI up and running? We will use the free version of Code Red to start with and upgrade if we run out of the 128kB code size limit.

Staying with emWin, we could also go for the Keil MDK-Professional, wich comes complete with emWin but not limited to NXP integrated controllers only. This means we can use a smaller processor with an SPI display. Drawback is that the Keil tools are not cheap. But they do come with other things like TCP/IP stack and more things that will be usefull for this and future projects. Anyone with experience on how good/fast this option is?

Any other suggestions for getting a good looking GUI running on a smallish (Cortex-M3, most likely) processor in not too much time?

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Been Transferred Lately?
Reply to
Stef
Loading thread data ...

I used to hear good things about PEG ("portable embedded graphics"), from the folks down three cubes and over four.

But the fanciest GUI's that I do these days are a serial port and some blinky lights, so I can't claim direct experience.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

If you're going to have that relatively expensive and power hungry screen, you may as well also use a more powerful processor. Then you can run a small X server and use a normal GUI toolkit. I did something like that on a small (64mb ram) Linux board using Python and Tkinter and it wasn't much different than programming a desktop GUI. These days, the smallest Raspberry Pi has 256MB and costs $25 and can run a full featured web browser, so trying to run a gui on a cortex m3 for a low volume product sounds kind of dubious.

Reply to
Paul Rubin

There do seem to be a few. The broadcom SOC in the RPi is particularly easy since the DRAM is in-package. I need to look into the others more.

Yes, a lot of these little boards are open source / reference designs that we are free to copy or use as a core of a product. Perhaps it is not so hard.

--

John Devereux
Reply to
John Devereux

The RPi is pretty much a "single chip linux", although it cheats because the DRAM is stacked on top of the CPU AIUI.

We know that a full linux+GUI is not feasible on any cortex-M single chip micro, but the discussion has broadened a bit. The OP was "Easy embedded GUI"; it is possible that the easiest is to use a linux+GUI embedded processor, based on or incorporating a RPi-like design. Not for very small displays / simple graphics perhaps, but it becomes more attractive for larger and high quality systems.

And you get to add wifi, say, by just plugging in a tiny $5 USB dongle and off you go. Or plug in a USB flash drive, or ethernet, or... All these things can be done on smaller chips but it is a learning curve and relatively expensive each time. With a linux based system you get to take advantage of the massive economies of scale and pricing of commodity parts, and the drivers are done.

--

John Devereux
Reply to
John Devereux

Not true. There are many M3 parts that support external memory (both flash and SDRAM). Look at the NPX LPC1800 parts -- they can execute from external SPI flash, external SDRAM, or any external static parallel memory (SRAM, NOR flash, etc.).

--
Grant
Reply to
Grant Edwards

NXP LPC1788 supports external SDRAM and can run even uClinux:

formatting link

--
Mikko OH2HVJ
Reply to
mi

As the OP has not stated which M3 processor he is using, this may not be helpful to his current design.

uClinux is not really linux, is it.

With out an MMU, its "toy" linux.

again, my $0.02

hamilton

Reply to
hamilton

And worth every penny :-)

uClinux is part of mainline Linux. It is missing some features that can't be implemented without a full MMU (these processors /do/ have an MMU, but it is much more limited than a "full" MMU, and doesn't support the copy-on-write mappings needed for efficient fork() support). But a useful subset of Linux software runs fine on uClinux. It used to be popular for a fair number of applications, such as routers, cameras, telephones, and a wide range of embedded systems with networking. However, these days bigger processors with full MMU's are so cheap that it is not hard to make a system supporting full Linux - and at the other end of the scale, there are other systems that give the developer a cheap (or free) networking stack and OS (in particular, FreeRTOS + lwIP). So uClinux is squeezed from both sides into an ever-narrowing niche.

So no, uClinux is not "toy" Linux - but it's heyday has passed.

Reply to
David Brown

There are M3 with and without external memory. Hardware is really simple if you stick with internal memory, a bit more complex if you need to add SDRAM, but not too much. But the bigger processors would need DDR memor and are in big BGA packages. And you would also need multi MB flash memory to boot from.

Software wise controlling the peripherals from C directly is a lot simpler and more straight forward than using linux device drivers. But that may be just my fear of the unkown. We have done a lot of bare metal C projects and a few using eCos, but no linux on our own hardware so far.

There you said it: "once you've done it a few times" That is just the problem, we have not done this kind of thing and there is a project with a time limit. Not the perfect situation for experiments.

As I understand it, the documentation of the Pi's Broadcom chip is not all out in the open (or has this changed recently?). Not very attractive for doing your own board based on that chip.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Never raise your hand to your children -- it leaves your midsection 
 Click to see the full signature
Reply to
Stef

At the moment I am not using anything. Im am trying to find the fastest way to a working prototype with GUI.

If the GUI can be kept simple (no linux etc.), the application will be able to run on a small M3 class processor.

One _option_ right now is using an LPC1800 because that can be used with a free binary distribution of emWin. Which is said to be very easy to work with and you should be up and running in days. That's nice to hear from a distributor, but some real life experiences would be helpful.

An option at the other extreme end is to run the prototype on a PC, using Labview. Problem with that is that the hardware will not fit in the prototype and must be hidden in a stand or something. It also means we cannot re-use anything, but experience, from the prototype when we start development of the production model.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

My sister opened a computer store in Hawaii.  She sells C shells down  
 Click to see the full signature
Reply to
Stef

Prototyping on a PC is still a perfectly good way to do things, per "build one to throw away".

I think with the M3 and the small screen you're describing, you're not going to want a fancy desktop-style gui anyway, but something more like an old fashioned phone interface. Will it have a touchscreen? I don't know anything about Labview or emWin but there have to be some small-screen toolkits out there.

I see there's a small touchscreen for the Arduino on Adafruit, that has some code:

formatting link
formatting link

Also a monochrome unit:

formatting link

Maybe some of that can be adapted.

Reply to
Paul Rubin

Hi, For small embedded graphic displays (ranging from 64x32 pixels B&W to QVGA), we had very good experiences with the GUI libraries from Ramtex

formatting link
: easily portable from processor to processor, easily adaptable to SPI or parallel displays, source code, and a very efficient simulator running on PC for the early development steps. Friendly yours, Robert

Reply to
Robert Lacoste

I'm not up to date, but I don't think you can buy it in less than xxx,000 anyway. (Exact value of 'xxx' unknown)

Theo

Reply to
Theo Markettos

Another reason not to use it then. If xxx==1 and samples are available, it may usable, but certainly not preferred.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

Even if you can deceive people about a product through misleading statements, 
 Click to see the full signature
Reply to
Stef

Yes, but if you can do a "build one, throw away half" in not much more time, it saves on the final model development. Additional bonus is that we may get the prototype electronics to fit in the prototype. But all is still open. But if we do end up with a PC prototype, the simple GUI question is just postpone, we still need a PC less final product.

No, no touchscreen required, only a few buttons on the enclosure. There are display modules for Labview available. And emWin is a small(and big)- screen toolkit.

I had a look at it and what they have done is the "easy" part of GUI development. The hardware access and some basic drawing primitives like line, rect etc. They claim text also, but I can't find that in 'lib' code. This basic stuff can be written from scratch in not too much time.

What is missing is the higer level stuff like buttons, screens, scalable fonts and a tool to make designing the GUI less painfull than coding it all by hand.

This is what emWin, and other packages suggested here, seem to offer. Would like to hear some first hand experiences with libs like that.

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

"Open Channel D..." 
 Click to see the full signature
Reply to
Stef

Thanks for the suggestion. This is a lot more basic the something like emWin. There seems to be the graphic primitives and text support. And also support for viewports and screens. But no pre-cooked gui objects or a 'design' tool as far as I can see. Correct?

Do you know how much time you spent to get a decent looking GUI up and running on a custom board? May I ask on what type of cpu you used it?

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail) 

You cannot achieve the impossible without attempting the absurd.
Reply to
Stef
[my apologizes if this appears twice]

formatting link

Reply to
hamilton

It's about time for my quinquennial plugin for Depui:

formatting link
I used it once, in a MS-DOS environment, so I can not comment about usage in a "true" embedded system, but it should be easy to port. (In particular when considering that an M3 may have more memory and certainly more processing power that what I used.)

--
Roberto Waltman 

[ Please reply to the group, 
 Click to see the full signature
Reply to
Roberto Waltman

Exactly. The only design tool is an icon editor, which generates icons in ".h" format for easy integration in C code. There is also a PC LCD simulator (fully sw or with interface to an actual LCD). The gui objects are your own...

Depends of course of the application. For basic graphical displays with May I ask on what type of cpu you used it?

Small ARM variants.

Robert

Reply to
Robert Lacoste

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.