[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- Date: Thu, 03 Feb 2000 00:58:17 +0100
- From: erwin at muffin.org (Erwin Rol)
- Subject: RTEMS GUI
AS i already wrote earlier i am looking for ppl and
information to make a base frame work for RTEMS to
make UI easier and more portable. But on an even lower level
than the video driver level from microWindows. More in the form
of a framebuffer. Of course there need to be some input devices to,
and because not (most don't) all embedded systems have a full PC
or a mouse, there must be some option to have small (and strange) input
Here a list with some things that i think are important.
Output device (framebuffer)
1) it must support small text displays
2) it must support small dot/matrix displays
3) it must have a defined interface
4) it must be possible to use without any input device
5) it must be posible to have multiple output devices
There small LCD's don't have a memory mapped framebuffer
there must be some "update" mechanism. If there is a memory
framebuffer than there will have to be a background task that writes
it to the LCD, if there are only put/get functions it could
happen in those fuctions (or one could use memory as a write trough
cache, so put write to the display , to the memory (while waiting on the
display for example) and get directly reads from the memory)
The linux framebuffer could be a base for a design. Any body
want to at remove anything from that list ?
1) it must support 2D relative devices (like mice, the
real mouse , not the cursor on the screen)
2) it must support 2D absolute devices (like touch screen, or joystick)
3) it must support 1D relative devices (like rotation knobs)
4) it must support 1D absolute devices (like faders, or potentiometer
5) it must support keyboard with 1 to X keys
6) it must be posible to use with out any output devices
7) it must be posible to have multiple input devices
Lots of emedded systems only have like 2 or 3 keys where they control
menues with on some small text or dot/matrix display. There must
be some features to poll the device , cause not all are IRQ driven.
keyboards could just be pins on a IO port of a uC/CPU. The polling
be hidden from the aplication, so there probably should be some task
to do the work and than q the results in some form. Those q'ed "input"
could than be read via the normal io/device-driver entry.
Anyone else some ideas on this subject ?
And now i am going to see if i get that mircowindows working :-)