AVR to LCD interface question

Hello,

I am working on my first embedded project (hobbyist) where I would like
to interface an AVR to a small touch screen lcd. I have an ATMega8535
on hand that I have been training to do simple tricks like flash LEDs
and whatnot. I have also ordered a 240x160 touchscreen LCD (Microtips
MTG-F24160BFWHSEB-18A). This LCD does not incorporate a controller,
just the segment drivers (NT7701/NT7702). It uses 4-bit data transfer.
The link to the datasheet is included below:

http://www.microtipsusa.com/product_pdfs/Graphic%20Module/240x160/MTG-F24160BFWHSEB-18A_20051028.pdf

As I understand it, controlling this LCD directly with the AVR would be
difficult at best, and wouldn't leave much capability in the AVR for
the rest of what I want to do. I've started looking for controllers,
and I've located an Epson S1D13700 (F01) LCD controller available in
small quantities.

http://www.erd.epson.com/vdc/pdf/13700/x42aa002.zip

Would anyone be willing to offer up an opinion as to whether this chip
would effectively tie the AVR to the LCD? Better yet, are there any
examples? My circuit design skills are extremely limited, so I hoping
for a simple solution not requiring a lot of glue. I hope that the fact
that this chip has the SRAM on-board makes simplicity a reality. The
touch screen stuff looks fairly straight forward using 4 of the
ADC-capable pins of the AVR - plenty of examples out there of how to do
it. Cost wise, the controller and LCD combo costs about $60, which is
quite a bit less than I've been able to find comparably sized T6963
based touchpanels.

Any hardware pointers would be much appreciated. My day job is
structural engineering and my electronics design experience/knowledge
is limited to 3 semesters of EE at college and what I can Google for. I
have written the low level Linux kernel driver bits for a MotionJPEG
video capture card, so I am fairly confident in the software side of
things. My eventual goal is to use this project as a platform to create
a controller that monitors several temperature sensors (thermocouples)
and adjusts a process accordingly - basically a homebrewed PLC/HMI.

Thanks for any help,
Matt

Gunny wrote:
> Hello,
>
> I am working on my first embedded project (hobbyist) where I would like
> to interface an AVR to a small touch screen lcd. I have an ATMega8535
> on hand that I have been training to do simple tricks like flash LEDs
> and whatnot. I have also ordered a 240x160 touchscreen LCD

8 bits resolutions would need 4800 bytes of video buffer.
How are you going to fit this in the 512 bytes SRAM of the 8535?

> ...

The S1D13700 has 32k of embedded SRAM that can be arranged in multiple
graphic, or text+graphic overlays. This SRAM can be written to (or read
from) in indirect mode with an 8-bit micro. I intend to generate the
image right in the controller buffer, but perhaps I am misunderstanding
the capabilities of the S1D13700. The actual data I need to generate
those displays should easily fit into 512 bytes ram.

If I understand Epson's application notes correctly, you could even do
a sort of double buffering by writing to one plane while it's Display
Attribute is off, then flipping it on.

Matt

Gunny wrote:
> 
> The S1D13700 has 32k of embedded SRAM that can be arranged in
> multiple graphic, or text+graphic overlays. This SRAM can be
> written to (or read from) in indirect mode with an 8-bit micro.
> I intend to generate the image right in the controller buffer,
> but perhaps I am misunderstanding the capabilities of the
> S1D13700. The actual data I need to generate those displays
> should easily fit into 512 bytes ram.
> 
> If I understand Epson's application notes correctly, you could
> even do a sort of double buffering by writing to one plane
> while it's Display Attribute is off, then flipping it on.

Your post makes no sense, due to the total lack of context.  GOOGLE
IS NOT Usenet, it is only a foul and abortive interface to usenet,
which presents a totally false view.  See my sig below, and the
referenced URLs, for means of using Google intelligently.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>
Also see <http://www.safalra.com/special/googlegroupsreply/>

CBFalconer wrote:
> Your post makes no sense, due to the total lack of context.  GOOGLE
> IS NOT Usenet, it is only a foul and abortive interface to usenet,
> which presents a totally false view.  See my sig below, and the
> referenced URLs, for means of using Google intelligently.

You're right, my apologies. Trying again...

linnix wrote:
> Gunny wrote:
> > I am working on my first embedded project (hobbyist) where I would like
> > to interface an AVR to a small touch screen lcd. I have an ATMega8535
> > on hand that I have been training to do simple tricks like flash LEDs
> > and whatnot. I have also ordered a 240x160 touchscreen LCD
>
> 8 bits resolutions would need 4800 bytes of video buffer.
> How are you going to fit this in the 512 bytes SRAM of the 8535?
>

The S1D13700 has 32k of embedded SRAM that can be arranged in multiple
graphic, or text+graphic overlays. This SRAM can be written to (or read
from) in indirect mode with an 8-bit micro. I intend to generate the
image right in the controller buffer, but perhaps I am misunderstanding
the capabilities of the S1D13700. The actual data I need to generate
those displays should easily fit into 512 bytes ram.

If I understand Epson's application notes correctly, you could even do
a sort of double buffering by writing to one plane while it's Display
Attribute is off, then flipping it on.

Matt

On 11/03/2006 the venerable Gunny etched in runes:

> CBFalconer wrote:
> > Your post makes no sense, due to the total lack of context.  GOOGLE
> > IS NOT Usenet, it is only a foul and abortive interface to usenet,
> > which presents a totally false view.  See my sig below, and the
> > referenced URLs, for means of using Google intelligently.
> 
> You're right, my apologies. Trying again...
> 
> linnix wrote:
> > Gunny wrote:
> > > I am working on my first embedded project (hobbyist) where I would like
> > > to interface an AVR to a small touch screen lcd. I have an ATMega8535
> > > on hand that I have been training to do simple tricks like flash LEDs
> > > and whatnot. I have also ordered a 240x160 touchscreen LCD
> > 
> > 8 bits resolutions would need 4800 bytes of video buffer.
> > How are you going to fit this in the 512 bytes SRAM of the 8535?
> > 
> 
> The S1D13700 has 32k of embedded SRAM that can be arranged in multiple
> graphic, or text+graphic overlays. This SRAM can be written to (or read
> from) in indirect mode with an 8-bit micro. I intend to generate the
> image right in the controller buffer, but perhaps I am misunderstanding
> the capabilities of the S1D13700. The actual data I need to generate
> those displays should easily fit into 512 bytes ram.
> 
> If I understand Epson's application notes correctly, you could even do
> a sort of double buffering by writing to one plane while it's Display
> Attribute is off, then flipping it on.
> 
> Matt

If you want to use the internal RAM of the S1D13700 it must be memory mapped and used in direct
mode. For this you will need a micro with an external RAM interface such as an Atmel ATmega128. If
the S1D13700 RAM is accessed in indirect mode it cannot be used as normal read/write storage
because the bus interface is double buffered. There is a useful discussion just now on the
AvrFreaks website.


http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&p=167272&POSTNUKESID=c817f1980367568
12c343cccf70943b8

Hope this helps.

-- 
John B