views:

2471

answers:

11

It seems that any kind of graphic library like DirectFB or MiniGui requires some sort of underlying operation system like Linux or uClinux.

I am challenged with writing a software for a micro controller with just 512kb flash, an LCD display and a touchscreen to display and handle some pictures and GUI parts.

Do you know any library which just need a pointer to the video memory that also can handle lines, images and fonts?

A: 

512kb is small. Good luck!

You might want to try a dsl combined with mplayer. The latter does not need a GUI to display a movie. I guess it could also display images.

Nonetheless I fear it will be too much for your flash. Maybe the source of these links will help.

Burkhard
+2  A: 

If your requirements for interactivity and GUI widgets are very modest (or you're OK with designing your own widgets), have a look at LibGD. Draw the image you want to appear on the screen using the library's functions, and then write it to the frame buffer using gdImagePngToSink().

Diomidis Spinellis
+2  A: 

The important thing you should be concerned about is the controller of the LCD and touchscreen. There is an abundance of C libraries (not free) for that task. A quick google got me these results: Simplify Technologies and Ramtex.

If you want to find something open source, then start from your controller's type and search embedded devices forums (even if it isn't ARM, you could easily port C code). Some suggestions:

Also, some kit manufactures offer an SDK (both with and without Linux) with their boards. Purchasing a board usually gives you the license to use the code. Search for development boards with the same LCD controller.

kgiannakakis
A: 

My guess is that something like FreeDOS, combined with DJGPP as a toolchain, and Allegro as a graphics library might conceivably fit into 512k of flash and still do a reasonable job (I'm assuming you have an x86 which has several Mb of ram here)

But these things are very x86 specific (Allegro is not though).

It is tricky to get a Linux kernel and a useful amount of userspace software inside 512k (but possible to get SOMETHING in)

MarkR
+5  A: 

We have used "PEG", the C++ version, from Swellsoftware for many years. It is commercial software, not free, but the underlying screen driver can use just a pointer to graphics memory and they provide many sample drivers for different types of graphics hardware. We wrote our own custom driver(s) for our proprietary hardware, using the sample drivers as reference. We have always had some sort of RTOS, but I believe PEG+ can also operate without an OS.

Check it out here: http://www.swellsoftware.com/

good luck,

M. Esh.
+3  A: 

By the time you incorporate some third party solution you could have just written it yourself.

For most if not all environments the screen is just a two dimensional array of pixels. Sometimes palletized sometimes not, but that doesnt matter, you can write yours however you want.

There is tons of free code out there for drawing lines and arcs, etc.

The killer may be fonts but I think you will find that a third party app will chew up all of your memory just doing fonts, you are resource limited so you will want to pre-compute the fonts and just copy the bits.

Make a two dimensional array of data, do all of your work on your favorite host at first, it is trivial to save .bmp files if you want to see what you are drawing, and trivial to turn a series of .bmp files into a video if you want to watch some action.

If you use generic C, and no libc calls (write your own memcpy, memset, etc) this code will run anywhere, on the host for development and on the target.

Fonts are going to be your killer you have to pre-compute them but manage to squeeze that info down into as small as you can, and at runtime extract the data and copy the bits for each letter into the virtual screen as fast as you can.

Or just buy one of the many lcd solutions that do all of this for you and you simply send it commands like draw "Hello World!" at some (x,y) using blue as the foreground and white as the background.

Basically I think the non-os solutions are still going to use too many libraries and be too big for your specific application. 2d arrays of bytes or pixels are trivial to manage yourself. Even if you are writing an application for a desktop platform I would do it this way and at the last minute copy the fully renedered screen update to some os dependent library (allows for maximum portability from one OS or not to another).

dwelch
+1  A: 

Not free, but good on low resource systems: http://www.tat.se and their products Kastor and Cascades. It only requires a pointer to video memory, malloc and something that looks like a file system. The last two requirements are not absolutely necessary either. No operating system is required.

Pär Bohrarper
Looks very impressive, thanks!
Mark Raddatz
+1  A: 

You probably need to compress fonts using Run Length Encoding (RLE). See the .pcx file format for examples, although it's probably best to design a custom RLE. You didn't specify the bit depth of the LCD, but fonts need either one bit per pixel if antialiasing isn't needed, or a maximum of three BPP with antialiasing. Every character has to have it's own width because monospaced text is not nice. You should render directly from the RLE compressed font to the screen, using an optimized routine.

SDL is a very portable graphics libary. It's used in embedded Linux systems, but I think it can be used without an OS. The nice thing about SDL is that you can use Windows / Linux to develop and test your UI, and later target your embedded system. No changes to application code needed!

You could also use the Anti-Grain Geometry library (http://www.antigrain.com/about/index.html) on top of SDL. With a 16 or 24 bit LCD it produces stunning graphics. It might be just a bit too large for your environment, because my executable on a ARM/Linux system was about one megabyte. It contained SDL, AGG and libfreetype2 for font rendering. AGG is also a little slow, but produces beautiful results.

Kasper Rönning
This are useful informations! It's a 16 bit color LCD with 640x480 pixel in size and I want using anti-aliasing for fonts, and other graphic stuff. I was also considering cairo, but it might be also too large.
Mark Raddatz
A: 

Hello,

Wow, I thought I was the only guy in the planet that was trying to write my own GUI for an embedded system using PICS.

After 2 years of coding I am able to do a very simple GUI which takes up about 50K. I am able to display any pictures, icons, and 4 sizes of a particular font with wall paper transparency if required. I have stored each charater in flash along with its respective width. I also selected pics and icons that I needed for my application and stored them into flash. I still didn't do antialliasing though. Up to now it has been an astronomical amount of work. I am using an LCD 1.5" 176 x 132 pixels with a pixel debth of 16 bits per pixel.

Asides from the advantage being able to write a software for a micro controller with just 512kb flash (or in my case 50K), I am still asking myself what other advatage is there for doing all this? What do ye all think!

All feedback appreciated!

Finest regards bob

A: 

You should give easyGUI a try.

easyGUI is a GUI graphics software/library specifically designed to work on small(er) Embedded Systems.

No operating system needed. A basic cyclic executive is enough. 512kb of Flash should be more than OK. The library easyGUI provides is very flexible in helping to minimize the amount of Flash you need.

Supports fonts, graphics, bitmaps, touch screens and a bunch of video controllers out of the box.

Plus it is really cheap (no licensing fees, just a flat amount per seat) and comes with a PC program to design screens and generate code. The PC program takes a while to get used to but in the end it is very nice to try certain things out on the PC and then just generate and watch it run on your target.

They have a demo app on their website. It is worth checking it out.

cschol
We're using it - it works well but you need a Windows machine to run the PC side of things.
peter_mcc
+2  A: 

For the smallest possible footprint you should really consider RamTEX. I have used it on two projects with 8-bit PICS. The ROM space was about 35K in my applications with ~1K for RAM (amount depends on whether you need RAM buffering for the display). ROM space depends on the graphical features you want or need.

They provide full source and the one-time price is quite good, less than $1000 (note that the prices listed on their web site have to be converted to dollars, or whatever your currency is). There are no royalties or per-product restrictions.

They provide a number of different size and style fonts and basic drawing calls (line, pixels, box, etc.). It does not have any defined "objects" such as buttons or menus, but I was able to implement a pop-up menu without too much trouble. It does support "viewports" that can be used to define text boxes, menus, etc, each with their own attributes.

It also comes with a simulator that runs on a PC so you can develop display code on your desktop before moving to an embedded system.

Doug Lonngren