LCD Interface
in [FPGA]
|
Prev: CPLD Jitter
Next: Hi-Z input
From: Pierre de Vos on 30 Aug 2005 16:36 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
From: Sylvain Munaut on 30 Aug 2005 17:55 Hi Pierre, Pierre de Vos wrote: > 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). Well, or more ... Using temporal dithering you can achieve about 16 gray levels if you want. (more and it starts to flicker). > 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? 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
From: Pierre de Vos on 30 Aug 2005 19:10 Hi Sylvain, "Sylvain Munaut" <com.246tNt(a)tnt> wrote in message news:4314d565$0$22061$ba620e4c(a)news.skynet.be... > Hi Pierre, > > Pierre de Vos wrote: >> 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). > > Well, or more ... > Using temporal dithering you can achieve about 16 gray levels if you > want. (more and it starts to flicker). > > >> 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? > > 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 > 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
From: Jan Panteltje on 31 Aug 2005 05:57 On a sunny day (Wed, 31 Aug 2005 01:10:30 +0200) it happened "Pierre de Vos" <pierre.devos(a)webmail.co.za> wrote in <df2p1d$7bj$1(a)ctb-nnrp2.saix.net>: >> 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 >> > >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 run length encoding?
From: Simon Peacock on 31 Aug 2005 07:03
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 "Jan Panteltje" <pNaonStpealmtje(a)yahoo.com> wrote in message news:1125482256.f96740eca6f82634996be6212a89288c(a)teranews... > On a sunny day (Wed, 31 Aug 2005 01:10:30 +0200) it happened "Pierre de Vos" > <pierre.devos(a)webmail.co.za> wrote in <df2p1d$7bj$1(a)ctb-nnrp2.saix.net>: > > >> 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 > >> > > > >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 > run length encoding? |