Graphics library for embedded systems without Linux? [closed]

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?

Answer 1

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,

Answer 2

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