nanogui: Re: Microwindows 0.87pre2 released for RTEMS
Subject:
RE: FW: Microwindows 0.87pre2 released for RTEMS
From:
Rosimildo daSilva ####@####.####
Date:
15 Dec 1999 01:31:40 -0000
Message-Id: <199912150125.RAA14957@www2.xoommail.com>
Greg Haerr wrote:
> : This is more a question for Rosilmido:
> :
> : What is the best way to deal with the various drivers for
> : Microwindows/RTEMS?
> : My concern is that this could explode in Greg's face. There are about
> : 40 BSPs
> : in RTEMS for 9 CPU families. Most of these can't support Microwindows
> : but
> : there is still the possibility for a LOT of variations.
> :
> : I suppose that they are dependent on Microwindows at least as much as
> : RTEMS.
> :
>
> I would like to include all drivers for Microwindows in the Microwindows
> source tree. Written properly, the drivers won't have much to do with
> RTEMS, but alot to do with the specific display hardware. The actual
> way that RTEMS maps the hardware (if any, since most will probably
> just be memory mapped at hard addresses) can be abstracted once to
> a separate routine in a separate file.
>
I think this is probably a good approach. I think we should
abstract the "hardware" ( kdb, mouse, video, touch-device, pen, etc ),
in a way that Microwindows does not have to have to know what CPU/BSP
the thing is running on. I do not know at this point if this is
feasible. For "character oriented devices" such as mouse, kbd
I think is very easy to accomphish it.
> For instance, that's how I built the Linux-based "framebuffer" routines:
> I have 4 planes VGA and linear VGA "drivers" that take an address
> and "draw" to it. In another file, for Linux framebuffer users, the mmap()
> system call is used to provide a mapping in the current process address
> space to the physical hardware. On real mode MSDOS and protected
> mode RTEMS, the same lower level drivers work by passing a protected
> mode-mapped constant address to the same routines. Thus, the
> drivers work on any system.
This is a very good way to "abstract the video device". I totally
agree with this idea. I'll study your code to see how we can
abstract this more.
>
> Rosimildo has written a serial driver for RTEMS, and included some
> special routines to interface our select() to RTEMS. Currently, the VGA
> driver and mouse driver are intertwined by Rosimildo, but he should
> probably seperate the "mouse-sequence processing" from the original
> mouse driver and place it in a separate file. This will then
> allow Microwindows to use the same source for mouse processing, with
> just a serial driver written for RTEMS, while under Linux we use /dev/ttyS1
> for the same purpose.
Sorry. I did a "quick and dirty" port to see if anybody
was interested on it. Now it is time for clean-up and
do it the "right way".
>
> A quick look at the Architecture document on the main web site
> http://microwindows.censoft.com shows how to write screen drivers.
> We can enhance that document for RTEMS specifically, if required.
>
> When Rosimildo finds time to check out the 0.87pre2 cut that includes
> the RTEMS integration, I will finalize a directory structure so that RTEMS
> ports are fairly straightforward...
>
I'll be looking at it over the weekend.
> In regards to the CPU families, I'm very interested in special fast routines
> to perform memory copies etc. These can be placed in new special
> directories,
> or dragged out of the RTEMS development libraries.
>
Which routines are critical ?
memcpy() ?
One more time, thanks Greg for the hard working that
you are putting on MicroWindows. You are leading this
project extremely well.
Rosimildo.
______________________________________________________
Get your free web-based email at http://www.xoom.com
Birthday? Anniversary? Send FREE animated greeting
cards for any occasion at http://greetings.xoom.com
