Re: [Lcd4linux-devel] [lcd4linux] Sharp LM40001G LCD

[Ernst B. <e.b...@xe...>]

On Wednesday 06 September 2006 06:52, Michael Reinelt wrote:
> Hi there,
>
> >>> Interfacing it seems a bit of troublesome, as it doesn't contain a
> >>> framebuffer, so all data has to be sent continuosly.
> >>
> >> So does the ledmatrix display, so you might be able to do something
> >> similar to its driver. 400 x  64 is 25600 pixels which in turn is 3200
> >> bytes. This does not fit into the memory of any of the small avrs,
> >> so you either use a mega128 (with 4k ram) or use an external ram.
> >
> > Yeah, probably some sram chip from an old '286 Mainboard, got plenty of
> > those left.
> > Then probably a pic18f4550, maybe ATMega16.
>
> Well, I'm afraid this won't work that easy... from a quick glance over
> the datasheet, it looks like the display consists of row and column
> controllers only, but no real lcd controller.
>
> These row/column drivers are controlled using a serial protocol, which
> is a) high frequency and b) very timing critical. Thats what a lcd
> controller is for.
>
> If you really plan to build an interface, you should really consider
> using a SED1550 or similar controller.

Hrmm. The original controller board has a Z80 CPU, a Z80 UART, Ram, EPROM with 
Os, an "Character Generator" EPROM, more Ram, a 7.3728 crystal, and a larger 
TTL graveyard.

I think it generates its pixel data with dual 74166 shift registers, and does 
all the character generation stuff in TTL. Hard to say more about it without 
schematic.

And since the pixel clock is only at about 500kHz (800uS for a line, 2uS for a 
pixel, 1/(2*10^-6)=500kHz, it should be possible to implement in an uC, maybe 
with help of two external shift registers.

Gotta test if shifting in software can be fast enough, unfortunatly those uCs 
only have one USI/MSSP that could help here.


> Wolfgang, are you listening? Your opinion?
>
> > With enough ram it would also be possible to implement two different
> > greys. Keep two framebuffers, display them alternating, keep one "on
> > screen" a little longer than the other (If the display timings allow
> > that)
>
> Again, I'm afraid this won't work, probably because of the "slowness" of
> the LCD display.

Yeah, probably. Since it would be "just" software, it can't hurt to try. If it 
doesn`t work, nothing lost.

/Ernst