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:

formatting link

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.

formatting link

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

Reply to
Gunny
Loading thread data ...

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?
Reply to
linnix

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

Reply to
Gunny

You're right, my apologies. Try> 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.

Matt

Reply to
Gunny

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

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.

formatting link

12c343cccf70943b8

Hope this helps.

--
John B
Reply to
John B

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.