Re: Micro to drive a TFT LCD

>
> Is a 24-bit (RGB) interface the best way (only way) to go for this? *Would
> prefer to use a 8 or even 16-bit interface if possible, it seems to be from
> the datasheet, but I am a bit fuzzy on the details. *We are not doing any
> sort of video, just data displaying some data with some minor graphics.

I have yet to see a TFT display which needs more than 16 bits to show
all it has. You'll certainly be fine at 16 bpp and likely OK for the
purposes you state at 8 bpp (but there will be visible limitations
at 8 bpp if you want to show photos or something, not huge on the
tiny qvga you want to use though).

I don't know either of the chips you are considering, if you build
your own TFT controller timing be aware that some displays might
not tolerate jittery sync and video signals (even though you have
their clock under control).

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tg...7600228621276/

Original message: http://groups.google.com/group/comp....2?dmode=source

Raddix skrev:
>> I have yet to see a TFT display which needs more than 16 bits to show
>> all it has. You'll certainly be fine at 16 bpp and likely OK for the
>> purposes you state at 8 bpp (but there will be visible limitations
>> at 8 bpp if you want to show photos or something, not huge on the
>> tiny qvga you want to use though).
>>
>> I don't know either of the chips you are considering, if you build
>> your own TFT controller timing be aware that some displays might
>> not tolerate jittery sync and video signals (even though you have
>> their clock under control).
>>
>> Dimiter
>>
>
> Thank you for the response.
>
> It looks to be possible to drive this controller with a 8 bit serial or up
> to 24bpp RGB parallel from the datasheet, and I am assuming i can get away
> with only driving the lower x bits (however that splits up...)of each color
> in the RGB interface. I will have to dive into setup and control of that
> quite a bit naturally, but i am more concerned with the sync controls.
> After looking at what may be involved with horizontal and vertical sync,
> and the fact that i can't depend on a single source for displays, i think
> it would be best to get a micro with an on-board lcd controller so i don't
> need to keep reinventing the wheel. Are there any other good low cost
> options available to control a tft display I may not be aware of? We
> already have all the tools needed to develop on most ARM chips, so I would
> prefer to stick to that if possible.
> A separate lcd driver chip would be nice to have, but my micro won't be
> doing too much else that will be very intensive on the CPU (acquiring data
> via UART, CAN and maybe Ethernet), so i should have plenty of resource
> available to do most of this on the controller. I also haven't seen a
> dedicated lcd controller for much less than $10 a pop, which could be more
> than my main controller.

Why not get an ARM9 based device.
Much, MUCH faster, and you can run Linux.
AT91SAM9263 would be a good choice.
200 MHz, UART, CAN and Ethernet + LCD controller
..

BR
Ulf Samuelsson


>
> Thanks again for the help and suggestions so far!
>
> ---------------------------------------
> This message was sent using the comp.arch.embedded web interface on
> http://www.EmbeddedRelated.com