"news.tin.it" <djordj@despammed.com> wrote in message
news:4a7c3d0b$0$34620$4fafbaef@reader4.news.tin.it...
>I need some idea to realize a structure like this:
> MCU <-> LCD CONTROLLER <-> TFT LCD
>
> I'm using a 32 bit MCU (ARM7 or Cortex-M3), supposed to drive external
> FLASH and SRAM.
> The TFT LCD has to be a QVGA-sized panel with no internal dedicated
> controller, has the company does not want to be be tied to a specific
> display model.
> We have this model to try with:
> http://www.data-modul.com/de/products/tft_displays/single_tft_small/TX14-Touch.pdf
>
> We have discarded the NXP2378 MCU and (obviuosly) old discontinued Sharp
> models.
> The graphic wuold be static: some 16bpp images and icons, with no smooth
> animations (max 2-3 frames per second): the company doesn't want to move
> to an ARM9 controller (or similar).
> So the choice will be as described above.
>
> Thanks
>
>
Hello,
Caught your thread late - see you have had a lot of not always useful
suggestions so I'll offer annother approach.
Look at www.solomon-systech.com for single chip controllers.
And at www.microchipdirect.com/productsearch.aspx?Keywords=ac164127-3 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 (www.angliacomponents.com)
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
www.mkesc.co.uk
Reply by vinnie●August 13, 20092009-08-13
>On Aug 7, 2:54=A0pm, news.tin.it <djo...@despammed.com> wrote:
>
>> > Have you considered an FPGA solution?
>>
>> Yes, but we're still looking at it.
>> Any idea?
>
>Well, what are you asking? No I don't have a ready-rolled design in my
>back pocket, though likely there is something at opencores that will
>serve.
>
>The reason I suggest it is because a simple LCD driver is not a
>complex project, and if you do it "soft" then you'll be insulated as
>far as possible against parts availability issues.
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.
http://america.renesas.com/h8lcd
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 by Henri●August 13, 20092009-08-13
On 7.8.2009 21:54, news.tin.it wrote:
> Dopo dura riflessione, larwe ha scritto :
>> On Aug 7, 10:41 am, news.tin.it <djo...@despammed.com> wrote:
>> Have you considered an FPGA solution?
> Yes, but we're still looking at it.
> Any idea?
>
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:
http://www.lcdinfo.com/projects/spi043_datasheet.pdf
A picture of a 4.3" test board:
http://www.flickr.com/photos/lcdinfo/3373047908/
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 by Dimiter Popoff●August 12, 20092009-08-12
On Aug 12, 7:18=A0am, Frank Buss <f...@frank-buss.de> wrote:
> ....
> Another solution would be to use an extra microcontroller and CPLD for th=
e
> graphics output, then you can implement other time consuming or realtime
> things in the main microcontroller.
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.
> But implementing it in a CPLD could be interesting, too. I have some Xili=
nx
> CPLDs with 32 macrocells, maybe I'll try it.
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.
> > Can you tell me where do you buy your SM502s from Cologne?
>
> I'm just the software guy in this project, but AFAIK they get it from
> HyLine.
> 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.
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.
> 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.
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:
http://www.frank-buss.de/vhdl/advancedClock.html
(full ISE project and updated source code with testbench:
http://www.frank-buss.de/tmp/plc-0.1.zip )
> And if power
> consumption comes into consideration, well....
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.
> Can you tell me where do you buy your SM502s from Cologne?
On Aug 12, 1:30=A0am, Frank Buss <f...@frank-buss.de> wrote:
> ...
> 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-ru=
n
> game :-) This would be 60*320*240=3D4.6 million pixels per second in the
> worst case, maybe with 16 bpp and you need to do some calculation, too.
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
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/bc8=
1272bc30458be?dmode=3Dsource
Reply by Frank Buss●August 11, 20092009-08-11
Dimiter Popoff wrote:
> 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).
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 by Sergey Kubushin●August 11, 20092009-08-11
Mike Harrison <mike@whitewing.co.uk> wrote:
> On Tue, 11 Aug 2009 23:42:10 +0200, Frank Buss <fb@frank-buss.de> wrote:
>
>>Dimiter Popoff wrote:
>>
>>> While Epson show numerous QVGA capable controllers, STM have none
>>> (just
>>> VGA -> LCD convertors).
>>> Siliconmotion are the only ones to my knowledge to make somewhat
>>> larger
>>> controllers since the b690x0 by Chips (intel, asiliant) were
>>> slaughtered.
>>> http://www.siliconmotion.com/ .
>>
>>The SM502 is really nice, once you've fixed some bugs in the sample code
>>they provide, e.g. in the line drawing function. Currently I'm using this
>>chip in a project. You can get it with integrated RAM and it has fast 2D
>>graphics acceleration functions. But of course it is BGA, so the OP could
>>not use it. I think the "no BGA" requirement is a big problem, because most
>>modern chips with fast LCD controllers are BGA.
>
> what sort of price is this chip?
Something like $15/1K.
---
******************************************************************
* KSI@home KOI8 Net < > The impossible we do immediately. *
* Las Vegas NV, USA < > Miracles require 24-hour notice. *
******************************************************************
Reply by Mike Harrison●August 11, 20092009-08-11
On Tue, 11 Aug 2009 23:42:10 +0200, Frank Buss <fb@frank-buss.de> wrote:
>Dimiter Popoff wrote:
>
>> While Epson show numerous QVGA capable controllers, STM have none
>> (just
>> VGA -> LCD convertors).
>> Siliconmotion are the only ones to my knowledge to make somewhat
>> larger
>> controllers since the b690x0 by Chips (intel, asiliant) were
>> slaughtered.
>> http://www.siliconmotion.com/ .
>
>The SM502 is really nice, once you've fixed some bugs in the sample code
>they provide, e.g. in the line drawing function. Currently I'm using this
>chip in a project. You can get it with integrated RAM and it has fast 2D
>graphics acceleration functions. But of course it is BGA, so the OP could
>not use it. I think the "no BGA" requirement is a big problem, because most
>modern chips with fast LCD controllers are BGA.
what sort of price is this chip?
Reply by Dimiter Popoff●August 11, 20092009-08-11
On Aug 12, 12:42=A0am, Frank Buss <f...@frank-buss.de> wrote:
>
> Regarding CPLD for a LCD controller: Maybe it is possible to fit somethin=
g
> which scans a framebuffer in 64 cells of a Coolrunner, but graphics updat=
e
> would be really slow, because I think 2D graphics acceleration are
> impossible with 64 cells.
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:
http://tgi-sci.com/tgi/vsn2.gif and
http://tgi-sci.com/tgi/vscs3.gif , 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
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/