mpc8xx and LCD

Chuck Meade chuck at
Fri Sep 30 03:31:52 EST 2005

> >>Can you send a couple of links to the modules you are considering?
> >there are some 320x240 from EDT (Emerging Display Technologies) with
> S1D13305
> >S1D13700
> >
> >
> >also from Powertip a 320x240 with S1D13305/ S1D13704 is available
> >
> >
> >and also from ampire is one ... (available /w or w/o Epson's S1D
> controller)
> >
> >
> Ok, I see the problem with the S1D13305, but the S1D13704 looks ok.
> In order to work as a linux framebuffer, the cpu must be able to directly
> address
> pixels.  You can't have a controller like the 13305 that makes you write a
> pixel address and then write the pixel.  A controller like the 13704 just
> makes
> the pixel memory look like RAM, so it's easy to interface.

I have done this in the past when the cpu could not directly access the
pixels.  I created a virtual framebuffer in RAM, and had a timer-driven
routine that regularly sent the contents of the virtual framebuffer to 
the LCD device through the "register bottleneck" of the LCD device interface.
It actually worked well.  I expected a big performance hit with all the 
additional bus activity, but it was not bad (no, I don't remember any
numbers).  The platform had a 48 MHz mpc8xx if I remember correctly,
and the LCD device was an old Epson chip that had a registered interface
(no direct access to pixels).

It is not an optimal situation, but if you find yourself stuck with an LCD
device that does not provide a RAM-like interface to the pixels, then it is
at least a known-working solution.

Chuck Meade
The PTR Group

More information about the Linuxppc-embedded mailing list