LCD Interface

Hi,

I've been struggeling with a long standing problem driving a 320x240 graphic LCD display. I've been using a LCD module with an Epson SED1335 controller chip. In my application the controller is quite susceptible to noise - it resets for no reason, exibits distortion of the image. Googling has come up with some other people also having similar symptoms with this controller.

I have mostly overcome the problem by adding additional filtering to the module - extra caps, ferrite on the cable, but the problem sometimes persists.

I've been looking at using a controller-less module and driving it directly from the FPGA I have on the board. The problem is that the Acex 1k30 I have on the board only has about 24k memory bits and the memory buffer for the LCD requires 76k bits (320x240).

I've been thinking lately that maybe I can compress the memory buffer, then write it to the FPGA and have the FPGA uncompress the buffer spitting writing the frame out to the LCD.

Any ideas on this technique or compression techniques?

Regards Pierre

Reply to
Pierre de Vos
Loading thread data ...

Well, or more ... Using temporal dithering you can achieve about 16 gray levels if you want. (more and it starts to flicker).

What kind of stuff are you displaying ?

For example if you have a user interface, maybe you can consider you screen as being a matrix of character to display text with some char being "icon". Imagine dividing 8x8 tiles with 256 possible chars. So the screen is

40x30 tiles = 1200 tiles = ~1.2 kbytes = 9.6 kbits to store what char to display in each tile. Then there is the content of the tiles themselves. With just B/W tiles, each tile takes 8x8 = 64bits, so you need 16kbits for the tiles memory. The total is 25.6 kbits, slightly above what you have but you can imagine only allowing to use 128 different tiles ...

If you have real _images_ to display then you need some image compression, that's quite harder and there is no guarantee that the image you'll need to store will be compressible into what space you have.

Sylvain

Reply to
Sylvain Munaut

Hi Sylvain,

It's a B/W LCD 1 bit per pixel and basically I display line graphics using an in memory frame buffer and blasting the buffer to the LCD from the CPU.

Pierre

Reply to
Pierre de Vos

On a sunny day (Wed, 31 Aug 2005 01:10:30 +0200) it happened "Pierre de Vos" wrote in :

run length encoding?

Reply to
Jan Panteltje

Although compression seems a good idea... Usually they will take more ram than you save when dealing with a small amount of data. I would suggest connecting to a small static ram or a single DRAM chip... a by anything will do... or even go to a more modern device.. the 1k family is a bit long in the tooth... an EP1C6 will give you ram to spare and is in a

144 TQFP (but has 4 less IO than the 1k30)

Simon

Vos"

have.

using

CPU.

Reply to
Simon Peacock

You could use an external dual port ram:

1) connect one port as read/write to system bus. 2) connect the second port to lcd_data as a rom. 3) create into fpga the clock, syncronization line, syncronization frame and connect it to lcd and the "rom" (second port of ram).

After, you should map the external memory into processor address space, as a matrix.

Then you could use the matrix variable to write/read into.

Marco

Reply to
Marco

"Pierre de Vos" schrieb im Newsbeitrag news:df2g0c$cji$ snipped-for-privacy@ctb-nnrp2.saix.net...

graphic

controller

up

You have a basic supply and noise problem. Just "adding ferrites and caps" doesnt solve it. You have to place the caps of the right type on the right place. Place 100nF ceramic cap close to VCC/GND of your module. Close means, make the wires shorter than 1/2 inch. Also place a 10uF electrolytic cap close to VCC/GND. Wire lenght can be longer, but keep it shorter than 2 inch. Make a good ground connection beteen the FPGA board and the LCD. A not too thin wire will do. Add 100pF to reset inputs of the LCD. This will catch spikes. Are all input pins of the LCD tied to a fixed voltage (VCC/GND)? Do not leave inputs open, unless is is guarenteed that they have internal pull resistors.

Good luck

Regards Falk

Reply to
Falk Brunner

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.