Re: [uCsimm] Color display

From: Tom Walsh (tom@cyberiansoftware.com)
Date: Tue Mar 13 2001 - 03:18:25 EST


Daniel Haensse wrote:
>
> Am Mon, 12 Mär 2001 schrieben Sie:
> > Daniel Haensse wrote:
> > >
> > > So there is a difference in the lcd-interfaces. I had a look at the optrex
> > > displays, but it supports only one bit per color (3bit=rgb). Is it possible to
> > > interface the display with a analog voltage to the data bits to generate scales
> > > (Resistor network)? Tom, can you tell me a manufactor?
> >
> > Sorry, it seems that I misunderstood your question. You wanted to
> > interface to an LCD Monitor rather than an LCD Display?
> No, you did understand my question. Sorry for my Germish ;-)

Yes, you're english is not that bad, you are doing fine.

> If you look at the optrex color display they use the 8 bits of the lcd interface
> to map it on the rgb pixels. One line is r1g1b1r2g2b2.... for d8,d7,d6,d5,d4...
> d0-d7 is a digital interface (no resistornetwork, no analog voltage for
> brightness)!? How is it possible to display scales? In my example with the
> optrex display it would have to turn a bit on and off for consecutive
> frames to obtain scales?!
>

Okay, what you are going to do is use the LCD DMA memory as a bit-pump
to get the data out of the ram into the latches of the display. The
problems you have are two:

1. the EZ328 can only outputs 4 bits out the data port. Solution: look
at how the EP-9013 display is interfaced in the Lineo AppNote (online
someplace), or my EZ328SIMM design. You will see that the clock for the
data pulse is delayed (divided by two), the data strobe is used to latch
the even numbered nibbles so when the odd numbered nibbles arrive (next
data strobe) then BOTH nibbles are presented to the display as an 8 bit
byte. The drawback to this approach is that it does introduce some
flicker onto the display as your FRAME (entire screen) is not refreshed
fast enough. I got refresh rates of something on the order of 15-18ms,
the display requires 12.5-13.5ms refresh rate to avoid flickering.

2. Creating the bit colors to place into the LCD DMA RAM so that they
will be presented to the color LCD in their proper order at the proper
time. As to the proper order, you should be fine, the bits are not
successive and not divided up in interleaving raster lines (they get
presented 8 bits per dot on the line). You just have to pay attention
to which half of the byte that each nibble would be wired to (and maybe
the ordering of the bits within each nibble: 1234 or 4321).

These problems should be able to be overcome. The nasty problem is to
get a display with a slow refresh rate that would cut down on the
flickering (it is minor, but noticable, AND it tends to diminish the
intensity somewhat). Your real problem will be to draw things on the
display in a timely manner. I think that you are using the VZ328? With
the VZ328 you have more speed to get things done, so with some careful
programming of your display routines, you should get acceptable static
performance (no animation).

>From my experience: I had to do a lot of careful coding & tricking up
the graphics routines to get reasonable performance on a QVGA monochrome
(1 bit per pixel). I would NOT attempt to control a QVGA color with the
EZ328 (well, *maybe* a 4 bit color...).

Regards,

TomW

BTW. I am trying out my newly arrived copy of Kylix, pretty cool
running Object Pascal from a linux box!

-- 
Tom Walsh - WN3L - Embedded Systems Consultant
'www.openhardware.net', 'www.cyberiansoftware.com'
"Windows? No thanks, I have work to do..."
This message resent by the ucsimm@uclinux.com list server http://www.uClinux.com/



This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:42 EST