Implementing an 18bpp LCD on the XSCALE
- From: authorwjf <authorwjf@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 27 Mar 2006 07:49:01 -0800
Supporting an 18-bit LCD Panel in WINCE using the SA2 LCD controller built
into the INTEL PXA 270 XSCALE board.
I recently came across an issue while bringing up the platform on a new
design based on the MAINSTONE reference board. The issue was my LCD display.
The Intel board and built-in LCD controller claims to support 18-bpp LCDs,
but the included reference driver (SA2VIDEO.DLL) obviously does not. The
more I tried to sort this out the more confused I got. Then I began scouring
the Intel and CE websites. To my dismay, I saw lots of this same type of
inquiry, but no one explaining definitively what options I had, and, how to
go about implementing a solution.
I did run across several interesting threads, and someone who called himself
“Voidcoder” who claimed to have run into this same issue, and successfully
implemented his 18-bpp LCD with WINCE. Luckily for me, Voidcoder didn’t mind
sharing. Combining his insights with info I gathered from a couple other
developers on different newsgroups, I now have my display running also. For
what it’s worth, I thought I would try and jot down the exact process I went
through while it was still fresh in my mind.
First and foremost, I believe the guys at Intel really need to make some
hardware design recommendations up front for us OEMs concerning support for
18bpp. Yes, their controller can do it. So what. I can’t find a single
modern operating system that supports it. It’s too inefficient. The real
fix for this situation is to let us OEMs know before we invest in spinning
our boards that 18bpp is not a good idea and if for some reason an OEM needs
to use an 18bpp part, they should tie off the LSBs for red, green, and blue,
and wire the board up like a 16bpp device (5 red, 6 green, 5 blue).
Ultimately, this is the fix for me. But I now have 100 boards or so I must
use up with the implemented software fix I am about to describe.
Could of, should of, would of. Enough said. If your reading this in the
first place it’s because you already have a board with an 18bpp display you
need to get running. I will say definitively that unless you want to rewrite
the entire display driver, and want to impact your system greatly in terms of
performance, you simply won’t be running your 18bpp LCD (wired up for 18bpp)
in anything but 8bpp color. What you will need to do is load a standard
24bpp system palette, pull of the 6 MSBs for red, green, blue, and then map
these to an internal palette on the SA2 controller.
In a nutshell that means you will need to:
1) Set up the registers for the controller for 8BPP. Set the LCD_PAL_FOR
for b10. Set the LCD PDFOR for b11.
2) Select 8bpp in the driver. The driver that comes with MAINSTONE lets you
do this and goes ahead and correctly calculates the frame buffer size for
you. If this isn’t what you’re using, make sure you have set up a frame
buffer for your height * width * 1 (i.e. 8bpp).
3) You’ll need a ram buffer for your palette, and a DMA descriptor for it.
Again the SA2VIDEO driver does this automatically when it detects a pixel
depth less than 16.
4) Next you will need to load a default palette. I used one called
“syspal.h” that I found in one of the platform builder directories. These
values are 24-bit colors, and will need to be truncated, and then remapped to
the internal 18bpp palette. In the case of the driver included with the
MAINSTONE, you’ll want to go into the “DispDrvrSetPalette” function and
modify the line where v_pPaletteBuffer gets assigned its values. I ended up
with something like this:
v_pPaletteBuffer->palette[i]=(
((DWORD)(source[i].peBlue >> 2)<<2)|
((DWORD)(source[i].peGreen >>2)<<10)|
((DWORD)(source[i].peRed >>2)<<18));
5) When you set up your frame descriptors, the LDCMD command used to set the
palette length must get modified (thanks Voidcoder—this one was a bugger).
The LCD_LEN needs to get set to 1024.
6) Finally, you may need to dig into the code and make sure 8bpp format is
being used when: creating the DDGPESurf, the return value from GetModeInfo,
your drawing primitives, and cursor functions. In my case using the
MAINSTONE video driver I only ended up having to tweak the cursor functions
(they appeared chunky and distorted at 8bpp as they were apparently intended
for 16bpp).
So there you have it, my words of wisdom. Which are mostly the words of
others I collected over a couple week period in the process of getting my
video up and running. Hopefully, having all the info in one place will save
others some time. Both developers like you who are trying desperately to get
your video running, and developers like “Voidcoder” who I bet gets tired of
answering the same questions over and over and over. Good luck!
.
- Prev by Date: Re: DCOM security warning
- Next by Date: Re: 8 bit to 18 bit per pixel lookup palette
- Previous by thread: malloc & HalAllocateCommonBuffer
- Next by thread: USR5421 on CE.50
- Index(es):
Relevant Pages
|
