>> I really like the flexibility of this line with the pin compatibility
>> within the family, as well as the much lower price compared to the lpc
>> chip. =A0I have very little experience with tft displays and don't want
t=
>o
>> waste all my time setting up the display if most of the work can be
done
>> with a dedicated peripheral.
>
>The fastest path, and least expensive, is to you the Renesas Direct
>Drive LCD reference design. It uses a Flash MCU, DMA, timers, and
>external frame buffer to directy drive a TFT panel (3.5 to 10.4) The
>panel doesn't require a controller, so you aren't locked into a
>specific vendor and COG.
>
>Check out the info posted here: http://america.renesas.com/h8lcd
>
>--CG

Oops. I forgot to mention that the "Direct Drive" H8S and H8SX MCUs are pin
compatible with each other, so you can choose how the chip based on
peripherals you need. 

Plus the H8S has been around for a long time, and is supported by GCC, IAR,
etc. And most of the software work for setting up the LCD panels is done
for you.

--CG	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com

On Oct 23, 3:18=A0pm, "Raddix" 
wrote:
>
> Is a 24-bit (RGB) interface the best way (only way) to go for this? =A0Wo=
uld
> prefer to use a 8 or even 16-bit interface if possible, it seems to be fr=
om
> the datasheet, but I am a bit fuzzy on the details. =A0We are not doing a=
ny
> 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_tgi/sets/72157600228621276/

Original message: http://groups.google.com/group/comp.arch.embedded/msg/a85=
d93f57aa43e92?dmode=3Dsource

On Oct 23, 8:18=A0am, "Raddix" 
wrote:
> I am looking to drive a 3.5" tft display similar to the one used in the
> following protoboard.
>
> http://olimex.com/dev/lpc-2478stk.html
>
> We were considering using the lpc2478 for awhile with its dedicated lcd
> controller. But I was looking at the stm32 chips (107/8) and i am curious
> about how feasible it would be to drive the onboard HX8238 of the tft wit=
h
> the FSMC of the ST chip and some timing outputs for the HSYNC and VSYNC.
> Is a 24-bit (RGB) interface the best way (only way) to go for this? =A0Wo=
uld
> prefer to use a 8 or even 16-bit interface if possible, it seems to be fr=
om
> the datasheet, but I am a bit fuzzy on the details. =A0We are not doing a=
ny
> sort of video, just data displaying some data with some minor graphics.
>
> I really like the flexibility of this line with the pin compatibility
> within the family, as well as the much lower price compared to the lpc
> chip. =A0I have very little experience with tft displays and don't want t=
o
> waste all my time setting up the display if most of the work can be done
> with a dedicated peripheral.

The fastest path, and least expensive, is to you the Renesas Direct
Drive LCD reference design. It uses a Flash MCU, DMA, timers, and
external frame buffer to directy drive a TFT panel (3.5 to 10.4) The
panel doesn't require a controller, so you aren't locked into a
specific vendor and COG.

Check out the info posted here: http://america.renesas.com/h8lcd

--CG

Raddix schrieb:

> We were considering using the lpc2478 for awhile with its dedicated lcd
> controller. But I was looking at the stm32 chips (107/8) and i am curious
> about how feasible it would be to drive the onboard HX8238 of the tft with
> the FSMC of the ST chip and some timing outputs for the HSYNC and VSYNC. 
> 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.

There are other displays with ILI9320/9325 or HX8312 Controllers, which 
have a standard CPU bus interface (80xx/68xx). No need for a certain 
timing, easy to handle.

A first place to look is http://www.gpegint.com/tft_small.html

-- 
Mit freundlichen Gr��en

Frank-Christian Kr�gel

>
>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
>

Interesting suggestion...  While we would prefer to avoid a BGA chip it
wouldn't totally be out of the question.  Only a couple bucks more
expensive in quantity compared to the LPC2478 for quite a bit more
processor.  Been tempted to go to an ARM9 and play with Linux, but may be a
bit overkill for what we really need to do. We also don't have any Linux
gurus around to aid in that kind of development, I play around with it on
the side, but nothing too serious.  Still could be a decent chip to use...

Thank you for your input!	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com

-vinnie- wrote:

> 
> The fastest path, and least expensive, is to you the Renesas Direct
> Drive LCD reference design. It uses a Flash MCU, DMA, timers, and
> external frame buffer to directy drive a TFT panel (3.5 to 10.4) The
> panel doesn't require a controller, so you aren't locked into a
> specific vendor and COG.
> 
> Check out the info posted here: http://america.renesas.com/h8lcd
> 

That's the coolest idea for an lcd driver i've seen for some time, 
though with the price of some micros being what they are, you could 
dedicate a separate micro for the lcd controller, perhaps using internal 
ram, and still be in pocket compared to stuff like the epson 
controllers. More programmability as well...

Interesting times indeed...

Regards,

Chris

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

>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.

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

I am looking to drive a 3.5" tft display similar to the one used in the
following protoboard.

http://olimex.com/dev/lpc-2478stk.html

We were considering using the lpc2478 for awhile with its dedicated lcd
controller. But I was looking at the stm32 chips (107/8) and i am curious
about how feasible it would be to drive the onboard HX8238 of the tft with
the FSMC of the ST chip and some timing outputs for the HSYNC and VSYNC. 
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 really like the flexibility of this line with the pin compatibility
within the family, as well as the much lower price compared to the lpc
chip.  I have very little experience with tft displays and don't want to
waste all my time setting up the display if most of the work can be done
with a dedicated peripheral. 

Thank you for any help

	   
					
---------------------------------------		
This message was sent using the comp.arch.embedded web interface on
http://www.EmbeddedRelated.com