GUI for embedded systems

Hello,

Could someone point me to something that could help me creating/understanding GUI for embedded systems in general? What's the "easier" (I know "easy" could be relative) to get GUI on an embedded system?

The hardware I'm looking for is ARM-based microcontrollers (Cortex M3, ARM7 or ARM9).

I think Qt could be a solution right? However I would like to know "lighter" alternatives.

Thank you!

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

formatting link

Reply to
msr
Loading thread data ...

Search around for "PEG" (I think it stands for "Portable Embeddable Graphics"). I've seen it used to great advantage in a nice small system. At the time (10 years ago) the licensing was reasonable, but it is $$ software.

Depending on the demands of your GUI you may just want to roll your own

-- Qt is, AFAIK, a "big system" GUI-maker; I very much doubt that it'll be even remotely as light weight as PEG.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

msr wrote: > Could someone point me to something that could help me

That depends a lot on the nature of your application -- the hardware you have available (for the display, "pointing device", etc.) as well as the sophistication of that UI and the other responsibilities of the system as a whole...

And what are you planning on using for the display, etc.? Are you looking at a QVGA panel? Something *smaller*? Larger? Color/monochrome, etc.?

Qt is bloated. What can you *afford* in your hardware budget (processing power, CODE+DATA resources, etc.)?

I've enjoyed using Inferno for small/quick-turnaround projects. The UI is Tk based (some folks find that wonderful; others find it regrettable :> ). Not as glitzy as some other approaches but you can hammer out a UI in very little time (taking advantage of the nature of Tk).

I haven't sorted out where it sits on the performance curve... but, I imagine it is on a par with a Qt solution in terms of processor burden. (I have an app running on a 90MHz *486* that yields "tolerable" response times!)

Of course, you're pretty much stuck with Inferno itself if you go this route (which "some folks find that wonderful; others find it regrettable" ;-)

HTH

Reply to
D Yuniskis

Scale? A one-off for your own learning/experimenting or thousands of units per month in a life-critical application environment?

On the one-off, it's for fun end of things, look at the BlueScreen dev board at Sparkfun

The color touchscreen LCD is pretty easy to drive and it gives you a chance to roll yer own primitives and build up from there.

--
Rich Webb     Norfolk, VA
Reply to
Rich Webb

Though PEG has some limitations. (Unless it has changed since I looked at it) it doesn't provide built in menu/dialog creation. If your GUI requires these features you have to build them yourself from the basis building blocks that PEG provides.

BTW PEG is a C++ class library. If the OP wants to code in C he needs the C/PEG varient

tim

Reply to
tim....

Qt is also C++.

But yes, if he wants C he needs something different.

--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

Also look at uC/GUI from Micrium/Segger. It should do what you want.

--
Scott
Validated Software
Lafayette, CO 



__________ Information from ESET NOD32 Antivirus, version of virus signature
database 5115 (20100514) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com
Reply to
Not Really Me

Thank you all for the responses and suggestions!

English is not my mother tongue, so I have some difficulty in express myself clearly, but if you dont mind I will try to explain my doubts better.

I would like to understand how GUIs are made in general (ie, depending on the requirements, from the most demanding to the less demandig). From a simple mp3 player GUI (monochromatic) to industrial displays controlling/monitoring machines (color, few buttons on the screen, dialogs, menus, etc).

For the most demanding systems, maybe Qt+Linux+WinCE were some (which more?) of the keywords. But what about "smaller" systems?

Say, I have a board (pcb) which controls a robotic arm and I want a small user-interface (a "specialized" LCD, not a desktop or laptop) to interact with that (move up, move down, etc). How can I acomplish that?

What frameworks/libraries/toolsuites are there to create small embedded GUI?

(note that Im looking at ARM, so 32 bit microcontrollers)

Thanks again!

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

formatting link

Reply to
msr

I think the first thing you may be missing is that many smaller GUIs are hand-rolled for the purpose at hand. A really basic graphics framework (like PEG), is mostly there to manage frames, keep track of which frames are 'above' others, and make sure that the 'top' frame doesn't get painted over by a 'lower' one.

But when you get right down to it, someone still has to think through what a typical user is going to be comfortable with, and program an interface that works -- there are guidelines that you can follow for that, but I know of no frameworks* for such systems.

  • Commercial ones. Every place I've ever worked at but one that had a GUI with menus has ended up with at least a rudimentary menuing system that captures menu behavior in some object-oriented way.
--
Tim Wescott
Control system and signal processing consulting
www.wescottdesign.com
Reply to
Tim Wescott

I still don't see that you need a complex GUI to control this.

Unless perhaps you are wanting to draw a "map" of the arm's location, on the screen.

Or are you using a touch screen?

The BSP that comes with development boards should be sufficient for a basic textual GUI.

Do you need anything more complicated than this?

tim

Reply to
tim....

I shall recommend a book that I think will explain some of the concepts for you.

Front Panel: Designing Software for Embedded User Interfaces by Niall Murphy

I think it will help you enormously.

--
********************************************************************
Paul E. Bennett...............
Forth based HIDECS Consultancy
Mob: +44 (0)7811-639972
Tel: +44 (0)1235-510979
Going Forth Safely ..... EBA. www.electric-boat-association.org.uk..
********************************************************************
Reply to
Paul E. Bennett

Sure! The robotic arm example may not be the best. Look at this mp3 player GUI:

formatting link
(monochromatic)

the

In the robotic arm example, yes! Just suppose you want a "fancy" user-interface (with touch screen) to control something and/or also display some info in a "fancy" and user-friendly way. Another (better) example: a train tickets machine, with buttons, menus for ticket type, destinations name, etc That should be very easy to use and a touchscreen GUI would be very helpful. In this case that GUI may be more sophisticated than the mp3 player GUI, I mean, with color, some graphics, etc

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

formatting link

Reply to
msr

This is a simple "text and line" GUI. You should be able to build this yourself from the basic LCD building blocks

The ticket machine isn't that hard to do because the buttons are always in the same place on the screen all that changes is the text inside them (and their function).

Adding colour and graphics doesn't make it hard to implement.

What makes it hard to do, and thus requires you to build a solution using a purchase API is the requirement to move things around the screen dynamically.

tim

Reply to
tim....

Such a system would typically be built using a "desktop" OS and GUI toolkit, e.g. Windows or Linux+Qt. Adobe Flash is also quite popular.

It's not uncommon to see Windows BSoDs on ticket machines, departure/arrival listings, ATMs, video billboards, etc; e.g.:

formatting link

Qt is quite widely used on mobile phones and PDAs (Qt's developer, TrollTech, is now owned by Nokia), as is WinCE.

AFAICT, PEG is aimed at the level below that, where you might only have an

8-bit or 16-bit CPU or RAM measured in kilobytes rather than megabytes (it will run on more powerful systems, but then it's competing with Qt and WinCE).
Reply to
Nobody

I can't agree with that assessment

I have worked on two systems where PEG was considered as an appropriate GUI framework (one rejected it in favour of an "own" solution and the other used it) and neither of these were 8 or 16 bit systems with limited memory, they were both 32 bit systems with 100s of megabytes.

In both cases, it came down to licensing cost.

tim

Reply to
tim....

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.