This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: LCD on EP7211
- To: Fano dot Ramparany at rd dot francetelecom dot fr
- Subject: Re:[ECOS] LCD on EP7211
- From: "Lewin A.R.W. Edwards" <larwe at larwe dot com>
- Date: Fri, 02 Feb 2001 09:26:59 -0500
- Cc: eCos Disuss <ecos-discuss at sourceware dot cygnus dot com>
Hi Fano,
> > I've interfaced a color QVGA LCD, which is working great! (with
>
>What are the exact references of the color LCD you are using on the
>EDB7212, and how difficult is it to adapt the driver to this new screen?
>There's
>an application note available on Cirrus Logic web site dedicated to the use
>of a color screen. Did you use this documents?
I did use that document (AN179) as a starting point. However, the version
that Cirrus had on their website [at least until recently] shows the
nibbles to the LCD swapped. They did update this, however I find that the
new document is still wrong, at least for my LCD it gives scrambled output.
I had to work out by trial and error which data lines from the EP7212
should go to which data lines on the LCD.
My LCD is an 8-bit-interface parallel CSTN LCD made by Nan Ya. Touch screen
is an option, we have not ordered it though (touch screens always get
covered in fingerprints, which is bad for a digital picture frame!)
The only LCD code I am using from eCos is a heavily adapted (i.e.
non-general-purpose) version of the lcd_on function. I am also not using
any of Cirrus's LCD code. My GDI is much more complicated than any of the
sample code that is available to me. The reason for this is that I have to
support:
* Fast YUV to RGB colorspace conversion for displaying MPEG video ;)
* Pretty much instant screen rotation (so that user can flip the frame
between portrait and landscape orientation and all GUI elements will
redisplay correctly).
* Scalable proportional-space fonts (as well as a simple debugging-type 8x8
fixed-space font engine based on the eCos code, this quick and dirty engine
is used in the flash upgrader code)
* Must support other video devices. The 4:4:4 model is only used in the
lowest-end passive model. The higher-end models use an external TFT-LCD
controller for higher resolution, 16bpp and 24bpp display modes.
* Some very simple realtime 3D code (mapping JPEG images onto a couple of
simple polygons for cool effects bouncing images around the screen and
making polyhedra out of them). This is very "fun" to do quickly in the
4:4:4 3bytes=2pixels model :/
Because of all these requirements, a lot of the code can't really be
optimized. I have written some very suboptimal (performance-wise) code that
works in the general case situations. Later in the design cycle I will
write platform-specific optimized functions.
=== Lewin A.R.W. Edwards (Embedded Engineer)
Work: http://www.digi-frame.com/
Personal: http://www.zws.com/ and http://www.larwe.com/
"Und setzet ihr nicht das Leben ein,
Nie wird euch das Leben gewonnen sein."