mpc8xx and LCD

[Chuck Meade]

> >>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
> >http://www.actron.de/graphic_displays_edt.htm
> >
> >also from Powertip a 320x240 with S1D13305/ S1D13704 is available
> >http://www.actron.de/graphic_displays_powertip.htm
> >
> >and also from ampire is one ... (available /w or w/o Epson's S1D
> controller)
> >http://www.ampire.com.tw/AmpireCatalogue/P082-AT320240Q3.pdf
> >
> 
> 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