From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Lewin A.R.W. Edwards" To: Fano.Ramparany@rd.francetelecom.fr Cc: eCos Disuss Subject: Re:[ECOS] LCD on EP7211 Date: Fri, 02 Feb 2001 06:28:00 -0000 Message-id: <4.3.2.7.2.20010202091410.00b3f270@larwe.com> References: <3A7A7F6E.7CBB489@rd.francetelecom.fr> X-SW-Source: 2001-02/msg00025.html 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."