Easy embedded GUI

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 
http://www.wescottdesign.com

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.

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

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

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

NXP LPC1788 supports external SDRAM and can run even uClinux:

--
Mikko OH2HVJ

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

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.

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 
unprotected. 
		-- Robert Orben

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  
by the seashore.

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:

Also a monochrome unit:

Maybe some of that can be adapted.

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

: 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

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

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, 
sooner or later the product will speak for itself. 
- Hajime Karatsu

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..." 
-- Napoleon Solo, The Man From U.N.C.L.E.

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.

[my apologizes if this appears twice]

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

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, 
  return address is invalid ]

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