Re:[ECOS] LCD on EP7211

["Lewin A.R.W. Edwards" <larwe@larwe.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."