mpc8xx and LCD

mpc8xx and LCD

[Fend, Matthias]

[-- Attachment #1: Type: text/plain, Size: 934 bytes --]

hello,

We want to use mpc860/855 with a 320x240 graphic lcd module.
Now there are many possibilities to interface such a module, but I guess this is
not the first time
someone will need a LCD display. So I'm trying to find out the most common way
to implement the 
desired functionality. 

At the moment I think we should use a lcd controller from Epson (S1D13700 or
S1D13305) since they are 
working on Linux framebuffer device driver for it. But I'm not sure how to
design the hardware interface ... all
the LCD modules I found provide only a reduced number of port pins so that the
controller only can be used
in indirect-mode, so I'm not sure whether to connect the module directly to the
CPUs bus or use some
GPIO pins for this...

Has anybody else implemented a LCD into a mpc8xx (not 823) board successfully ?
Are there some good resources somewhere in the web about this topic ?

thanks for your recommendations,
 mattthias


[-- Attachment #2: Type: text/html, Size: 1780 bytes --]

Re: mpc8xx and LCD

[Mark Chambers]

mpc8xx and LCD>hello,
>We want to use mpc860/855 with a 320x240 graphic lcd module.
>Now there are many possibilities to interface such a module, but I guess
this is not the first time
>someone will need a LCD display. So I'm trying to find out the most common
way to implement the
>desired functionality.
>At the moment I think we should use a lcd controller from Epson (S1D13700
or S1D13305) since they are
>working on Linux framebuffer device driver for it. But I'm not sure how to
design the hardware interface ... all
>the LCD modules I found provide only a reduced number of port pins so that
the controller only can be used
>in indirect-mode, so I'm not sure whether to connect the module directly to
the CPUs bus or use some
>GPIO pins for this...
>Has anybody else implemented a LCD into a mpc8xx (not 823) board
successfully ?
>Are there some good resources somewhere in the web about this topic ?
>thanks for your recommendations,
> mattthias

Can you send a couple of links to the modules you are considering?

Mark Chambers

Re: mpc8xx and LCD

[Dan Malek]

On Sep 29, 2005, at 2:53 AM, Fend, Matthias wrote:

> At the moment I think we should use a lcd controller from Epson 
> (S1D13700 or S1D13305) since they are
> working on Linux framebuffer device driver for it.

Well, check carefully.  As I recall, those parts have been
discontinued.  Although there is software, you may not be able to
build products once it is done.  I'd suggest looking first at
Fujitsu, and second at Silicon Motion.  Both of these companies
have claimed to be dedicated to providing the embedded
parts for a long time.

> Has anybody else implemented a LCD into a mpc8xx (not 823) board 
> successfully ?

Of course.  It has an internal LCD/video controller, and there should be
drivers in various kernels.

Thanks.

	-- Dan

Re: mpc8xx and LCD

[Mark Chambers]

hi,

>>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.  The only thing
different is that you must be able to handle wait states, because the pixel
memory is shared between the controller and the cpu.  The 13704 manual
has a section showing how to interface to an MPC821, so that's basically
the same as MPC860.  However, watch your DSACK0 signal closely - this
signal is shared with 8xx internal logic.  It must be synchronized with the
cpu clock, and you may not be able to just let a pullup resistor handle the
rising edge - if that rising edge leaks into the succeeding cycle you can
see
some weird intermittent problems.  So plan on needing to run WAIT from any
controller through some glue logic to clean it up for the 8xx.

Or you may be able to just get by with making your cycle time long enough
that you can ignore WAIT.  It sounds a bit ugly but as a practical matter
it won't affect performance much.

Mark Chambers

RE: 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

Re: mpc8xx and LCD

[Mark Chambers]

>
> Do you think it's possible to write the device driver in such a way that
> he also translates the pixel data into the indirect register mode of the
> S1D13700 ?
>

No, not directly.  The thing about frame buffer devices is that applications
write directly into the pixel memory (via mmap) so that's why hardware
compatibility is important.  But as Chuck Meade pointed  out, you can make
most anything work by writing a driver that copies from a virtual
framebuffer
to your hardware.

But if this is a new design, forget these indirect chips.  Step one, you
have
to find a controller that can drive your LCD.  Step two, make sure the
controller allows random access to pixels on the host side.  Step three,
if it comes with a driver, great, but if not, framebuffer drivers (for an
LCD)
are pretty simple and you should be able to modify one of the stock
kernel drivers to work for you.  Basically you just have to initialize your
chip and then implement a couple of IOCTLs to query and optionally set
the format of your pixels (and the mmap(), of course).

 --Mark