[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RTEMS GUI
From: Erwin Rol ####@####.#### Date: 2 Feb 2000 23:01:53 -0000 Message-Id: <3898C499.2731ED17@muffin.org> Hello All, 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 keyboard or a mouse, there must be some option to have small (and strange) input devices. 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 slow 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 ? Input device 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 like devices) 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. Small keyboards could just be pins on a IO port of a uC/CPU. The polling should be hidden from the aplication, so there probably should be some task running to do the work and than q the results in some form. Those q'ed "input" events 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 :-) - Erwin | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
RE: RTEMS GUI
From: Greg Haerr ####@####.#### Date: 3 Feb 2000 00:20:49 -0000 Message-Id: <C1962B36D9BBD311B0F80060083DFEFB0549D8@SYS.CenSoft.COM> The items Erwin is proposing can be made to work with Microwindows. I agree that RTEMS' design should start with just getting a framebuffer implemented. It is very easy for Microwindows to run on top of a framebuffer, just as it does for Linux. In this way, the mode switching text vs. graphics, etc is handled by the kernel, rather than Microwindows. In order to keep it simple, you could start with the basic VGA driver that I've written for Microwindows and just add it to the kernel. Actually, all that's really required is to add the graphics mode setup/takedown into the kernel, and have the abililty to map the video memory address to user mode, and then the same VGA driver minus the setup/takedown can be used. Later on, a implementing a linear buffer is definitely the way to go, for 8, 16, and 32bpp. In regards to the input devices, whether they're mice, kbd's, or touch panels, Microwindows Linux works by hanging on a select(). RTEMS uses rtems_event_receive. All that is required is that all the input devices all be able to funnel events and info thru a single mechanism. Look at microwin/src/rtems/rtems_select.c for details. Either the kernel or Microwindows can decode the input devices. It's probably better that RTEMS does, and then the same Microwindows can run on top of it. Having identical binaries for Microwindows and Microwindows' applications with the kernel modified for the hardware attached is better than having to recompile the applications or Microwindows for different hardware environments. Greg Hello All, 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 keyboard or a mouse, there must be some option to have small (and strange) input devices. 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 slow 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 ? Input device 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 like devices) 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. Small keyboards could just be pins on a IO port of a uC/CPU. The polling should be hidden from the aplication, so there probably should be some task running to do the work and than q the results in some form. Those q'ed "input" events 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 :-) - Erwin --------------------------------------------------------------------- To unsubscribe, e-mail: ####@####.#### For additional commands, e-mail: ####@####.#### | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |