Re: LCD Driver porting
- From: Valter Minute <vminute@xxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 11 May 2006 01:10:54 -0700
"guru" <gurunandan.ug@xxxxxxxxx> wrote in
news:1147269643.903786.106220@xxxxxxxxxxxxxxxxxxxxxxxxxxxx:
[...]
I am very new to Windows CE. Presently we are trying to port some
custom lcd driver written for nucleus rtos based system to win CE
based system. The problem we are facing is:
1) there is a third party graphics library which provides UI in
case of nucleus based system. We want exactly the same UI in
wince.
2)we want to port the whole software to wince OS based as
we require to add many new features to it for which no support is
provided in basic nucleus rtos.
Now the question which I want to ask is as follows:-
1)Is there any way or API for accessing the lcd device directly
from Win CE so that we can just perform little modification to
present UI library and use it in wince based system?
You can use DirectX to draw directly on the display (in this case
your code will be more portable) or you can remove the Windows CE
graphics, events and windows subsystem (GWES) and replace it with
your own version. In this case you should write your own display
controller "driver" (it could be a driver or part of your UI library)
and use GWES only for input or replace also this part.
As Steve Maillet pointed out, this is a large programming task and
you will lose part of the functionality of Windows CE.
If there is a Windows version of your UI library and you've got the
source code and the rights to modify it, you may try to port it on
Windows CE, without breaking the UI layer of your application and
keeping the features of CE that require GWES.
If you need to customize the appearance of the UI, you can do that on
Windows CE. Check the Networked Media Device feature pack for an
example of how can look a custom UI built on top of Windows CE GWES.
2)Are there any alternate way of accessing control register of LCD
using win CE API?
Alternate to what?
Usually the LCD controller is accessed by the display driver but it's
possible (but only if you don't have a better solution!) to access it
inside an application or a DLL library using APIs to map it's
registers (MMAPIoSpace) and then using them via memory access (ARM)
or I/O (x86).
This kind of UI management could be complicated if you've many
applications trying to access the display at the same time. On CE
this kind of synchronization is provided by GWES.
If you have many processes on your current RT os you may/have to
convert them to threads (you will have to do that if you have more
than 25-30 processes because CE has a limit of 32 processes and
you've to include, at least, the kernel, the device manager and the
filesystem manager and, depending on your device configuration, GWES
and the services manager, and for debug configurations, the debug
shell and the "servers" of the remote tools).
3)Is there standard support for 1/4VGA LCD driver on WinCE? Can we
include the driver for this device using Platform Builder?
The driver in CE is used to control the LCD controller (or graphic
card), not the "display" panel. You need (or have to write) a driver
for your LCD controller and then configure it to work at your desired
resolution and with the timings and data modes needed by your LCD
panel.
If you are going to work on a 240x320 portrait display, window CE
provide a component that will include in your image dialog boxes and
resource that will fit this display). If you're working in 320x240
landscape you may have to "retouch" some of the default dialog boxes
because the default UI is designed for a 640x480 VGA display and some
of the elements don't fit inside a smaller display.
--
Valter Minute
(the reply address of this message is invalid)
(l'indirizzo di reply di questo messaggio non è valido)
.
- References:
- LCD Driver porting
- From: guru
- LCD Driver porting
- Prev by Date: Where is "wzcshell.h"
- Next by Date: (608) communication error
- Previous by thread: Re: LCD Driver porting
- Next by thread: Active sync "Connecting to host" message
- Index(es):
Relevant Pages
|
Loading
