TFT LCD controller

g
e

Really slow? On a 320x240 pixels framebuffer? Come on, I used to do that fast enough using a 1 MHz 6809 >20 years ago. Nowadays, well, things are even faster and on an SXGA (1280x1024) framebuffer, no "accelleration" used at all (all windows are in offscreen framebuffers, a single MPC5200 at 400 MHz does the whole thing, its DMA doing system memory (where offscreen window buffers are) -> PCI framebuffer memory (over a 66 MHz/32 bit PCI).

Here are some screenshots, I toyed with a new system a while ago:

formatting link
and
formatting link
, the latter being an emulation of the above mentioned 6809 system in a DPS window, 50 or 100 times faster than the original, though (not sure, did not care to seriously measure that).

Of course 2D accelleration can be useful, (has been to me when all the CPU I had was a 25 MHz 68340 with 1M system RAM and an 800x600 pixles,

16 bpp screen...), as you suggest, but not in the slow context of the OP QVGA, his only issue seems to be how to have the framebuffer shown on a TFT module.

Dimiter

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

formatting link

------------------------------------------------------

formatting link

Reply to
Dimiter Popoff
Loading thread data ...

what sort of price is this chip?

Reply to
Mike Harrison

Something like $15/1K.

--
******************************************************************
*  KSI@home    KOI8 Net  < >  The impossible we do immediately.  *
 Click to see the full signature
Reply to
Sergey Kubushin

This depends on the definition of "really slow". I was thinking of 60 Hz realtime update of the whole content, e.g. for a flicker free jump-and-run game :-) This would be 60*320*240=4.6 million pixels per second in the worst case, maybe with 16 bpp and you need to do some calculation, too. Impossible for smaller microcontrollers. But your are right, if you have fat BGA CPUs with 400 MHz clock, it is possible.

Something like < 10 fps should work even on smaller CPUs.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

n

While that would be too fast to a 1 MHz CPU, 200 nS per pixel is nothing to write home about. A 25 MHz CPU32, almost 20 years old, would do that. A QVGA is just too tiny to make life hard to anything except the smallest of CPUs - and it would certainly be the better deal to use a CPLD + a CPU than to use a mosntrous FPGA. And if power consumption comes into consideration, well....

Can you tell me where do you buy your SM502s from Cologne?

Dimiter

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

formatting link

------------------------------------------------------

formatting link

Original message:

formatting link

Reply to
Dimiter Popoff

Yes, you can do it. But then you can't do many other things in parallel. And many small microcontrollers have limitations for the maximum GPIO output rate. Of course, modern microcontrollers, and even older CPUs, provides DMA. Then smooth scrolling at 60 Hz is possible. It depends on the requirements and how big your CPU is.

Another solution would be to use an extra microcontroller and CPLD for the graphics output, then you can implement other time consuming or realtime things in the main microcontroller.

The module with which I'll implementing it, doesn't use a monstrous FPGA like an expensive Virtex, just a small Spartan-3, a spartan FPGA :-)

But implementing it in a CPLD could be interesting, too. I have some Xilinx CPLDs with 32 macrocells, maybe I'll try it. The number of registers could be a problem for SRAM interface, if the CPU should write in parallel. For my programmable divider it was not easy to fit it in the device:

formatting link
(full ISE project and updated source code with testbench:
formatting link
)

Yes, this could be a problem. Quiescent current for the larger Spartan-3 versions could be more than 100 mW and I think a graphics acclerator would need some more power. And you'll need special voltage regulators for 1.2 V and 2.5 V, but this is available and endorsed by Xilinx from TI and other companies and already integrated on the DIL module I'll use. A TFT needs some power anyway, so maybe this additional power requirement is not a problem.

I'm just the software guy in this project, but AFAIK they get it from HyLine.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

e

The "normal" solution would be to use a CPLD+framebuffer RAM and instead of adding a processor just using one with somewhat more horsepowers.

Unless you can fit the 153600 bytes of framebuffer memory inside your FPGA, even the smallest one is too huge for the task in my book.

nx

32 cells won't get you very far. With 64 things would be marginal; 128 cells would be OK. I would use a TQFP100 coolrunner, comes with 64 and 128 etc. cells - and is really low power.

Thanks, I had not heard of them. May be I'll try them next time I am buying.

Dimiter

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

formatting link

------------------------------------------------------

formatting link

Original message:

formatting link

Reply to
Dimiter Popoff

If you are looking for an existing FPGA solution then here is one that I have made and that might be available for building into custom boards.

Simple document that aims to give a general idea of what kind controller it is:

formatting link

A picture of a 4.3" test board:

formatting link

The basic version uses 8 MByte of framebuffer memory. Being capable of storing multiple frames can be useful sometimes. For special needs up to

32 MB framebuffers have been used. In addition to the 4.3" TFT the controller has also been used with a Hitachi 3.5" QVGA display and then with some larger resolution panels too.

Henri

Reply to
Henri

Actually there's a perfect MCU solution to this problem, and it doesn't involve the complexity of an ARM9 core, or trying to recreate the wheel with an FPGA.

Renesas uses 16/32 bit MCUs with Internal FLASH and external SRAM/DRAM frame buffers for Direct Drive TFT solutions. Hardware and software are available in PDF and ANSI C to give a fast time to market.

formatting link

The software API and Hardware developer guides are available for download. It works with TFT QVGA, WQVGA, and VGA panels. The H8S MCU uses an External DMA to off-load the TFT data movement, so very little processing power is used to update the display.

--Vinnie

Reply to
vinnie

formatting link

Hello,

Caught your thread late - see you have had a lot of not always useful suggestions so I'll offer annother approach.

Look at

formatting link
for single chip controllers.

And at

formatting link
to see how to interface with micros.

Microchip even have links to tell you where to get the Solomon chips but in UK you canuse Anglia Components

formatting link

As ever Microchip are so helpful with apps support you almost want to use their processors - but you can still use the NXP ARMs !!

(BTW - if you are so concerned about long term availability why choose NXP ?)

Michael Kellett

formatting link

Reply to
MK

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.