Question

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?

Was it helpful?

Solution

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).

OTHER TIPS

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,

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().

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.

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.

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.

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.

(old question, but I wanted to post my findings on the subject)

For high-quality graphics, Anti-Grain Geometry is a good choice. It compiles to about 50kB and can be customized to write into all kinds of framebuffers and rendering devices: http://www.antigrain.com/

For user interface, Gwen appears a good choice. It is easily portable and can be customized to render either bitmap skinned controls or just rectangle/circle/line forms: https://github.com/garrynewman/GWEN

Then if you are also selecting an RTOS, NuttX has it's own graphics subsystem and widget toolkit: http://nuttx.sourceforge.net/

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)

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.

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.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top