Microcontroller with QVGA or VGA LCD controller
David Brown
controllers for QVGA (320x240) or full VGA (640x480) displays?
I've found a few large devices (a ColdFire v3 device, and a number of
ARM9's from Atmel) that have LCD controllers supporting much larger
screens, but these are pretty big and fast microcontrollers, with large
pin counts and needing sizeable external memories.
I'm hoping to find something a bit smaller and cheaper, and easier to
work with.
Stand-alone LCD controllers would be an alternative, if such a thing
exists these days.
Stef
David Brown <da...@westcontrol.removethisbit.com> wrote:
> Does anyone have any recommendations for microcontrollers with LCD
> controllers for QVGA (320x240) or full VGA (640x480) displays?
> Stand-alone LCD controllers would be an alternative, if such a thing
> exists these days.
We use the Epson S1D13706 in 8bpp mode for a QVGA display (TFT 18-bit).
--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)
"Computers in the future may weigh no more than 1.5 tons."
(Popular Mechanics, 1949)
David Brown
> In comp.arch.embedded,
> David Brown <da...@westcontrol.removethisbit.com> wrote:
>> Does anyone have any recommendations for microcontrollers with LCD
>> controllers for QVGA (320x240) or full VGA (640x480) displays?
> [...]
>> Stand-alone LCD controllers would be an alternative, if such a thing
>> exists these days.
>
> We use the Epson S1D13706 in 8bpp mode for a QVGA display (TFT 18-bit).
>
Thanks for that suggestion - it could well be that one of Epson's
display controllers (I see they have a whole series) combined with a
smaller microcontroller would be the best solution for us.
mvh.,
David
larwe
wrote:
> Does anyone have any recommendations for microcontrollers with LCD
> controllers for QVGA (320x240) or full VGA (640x480) displays?
What color depth? I'd suggest one of the low-end ARM7 parts such as
NXP (Sharp) LH79520 or Cirrus Logic CL-EP7312. You will still require
external memories and I don't think you'll get away from that anyway -
big displays need lots of framebuffer RAM and it's not common to find
a micro with 512K of on-chip RAM - rarer still for that to be an
inexpensive, low pin-count part.
You can also drive the panel directly in software. This isn't exactly
fun but it is doable. Of course you still have the RAM issue to
contend with, but at least you can make your own decisions about color/
text encoding, etc.
The Epson parts another poster mentioned exist, and they have on-chip
framebuffer. However they certainly don't have a low pin count (QFP
devices) and I would DEFINITELY not describe those parts as easy to
work with! You have to glue the bus onto your micro, which is not too
hard, but then you have to work with their semi-operable development
system to get the chip set up for your panel. Argh. Unless things got
a lot better since 2002, I wouldn't describe this as an easy route.
David Brown
> On Feb 27, 7:22 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>> Does anyone have any recommendations for microcontrollers with LCD
>> controllers for QVGA (320x240) or full VGA (640x480) displays?
>
> What color depth? I'd suggest one of the low-end ARM7 parts such as
> NXP (Sharp) LH79520 or Cirrus Logic CL-EP7312. You will still require
> external memories and I don't think you'll get away from that anyway -
> big displays need lots of framebuffer RAM and it's not common to find
> a micro with 512K of on-chip RAM - rarer still for that to be an
> inexpensive, low pin-count part.
>
I don't know off-hand what colour depth we'll be looking at (I don't
have the technical details on the displays as yet). My guess is that
the displays are 18-bit, and we can run them at 16-bit or 8-bit colour
depth. We haven't yet decided on the QVGA or VGA panel, or if we want
to support both - it depends on the options available. With
320x240x8-bit, the frame buffer is small enough to fit within the
internal memory of some high-end integrated microcontrollers - we're
considering many options at the moment.
If we find something that needs some external memory, that's OK - but
I'm hoping it will be something like a single SRAM device and the
microcontroller's internal flash, rather than external flash and large
fast SDRAM/DDR memories for a big processor.
The NXP part looks interesting - ARM7 is the sort of core we are
expecting to use. Their website is so awful that I gave up trying to
find anything by myself. I hadn't thought of Cirrus Logic (we have not
used ARM devices before, so I'm not familiar with all the suppliers),
but I'll look into their devices later.
> You can also drive the panel directly in software. This isn't exactly
> fun but it is doable. Of course you still have the RAM issue to
> contend with, but at least you can make your own decisions about color/
> text encoding, etc.
>
What sort of pixel clock are needed for a typical QVGA LCD panel (if
there is such a thing as a "typical" panel - I haven't got the technical
details yet)? I would guess it would be a few MHz - that's quite
demanding for a processor if it needs to do anything else. Perhaps
something could be set up using DMA transfers and some glue logic - but
then it might be just as easy to use a programmable logic device (which
is another possible solution - an LCD controller is pretty simple).
> The Epson parts another poster mentioned exist, and they have on-chip
> framebuffer. However they certainly don't have a low pin count (QFP
> devices) and I would DEFINITELY not describe those parts as easy to
QFP packages at around 140 pins are perhaps not low pin counts, but
compared to the 200-300 pin bga packages of the ARM9 and ColdFire v3
devices I found earlier, they are low pin count! I've done boards
before using large, fast bgas and memory buses before, but I'm hoping to
make something smaller and cheaper here.
> work with! You have to glue the bus onto your micro, which is not too
> hard, but then you have to work with their semi-operable development
> system to get the chip set up for your panel. Argh. Unless things got
> a lot better since 2002, I wouldn't describe this as an easy route.
>
I have no experience with Epson devices, but they do look a bit overly
complicated to configure. I had a look at the information about the
Linux framebuffer drivers for the devices (not that we'll be running
Linux on this board - it was merely for curiosity) - I thought it was a
little odd that to configure the chip you need a windows-only program!
Thanks for the info,
David
donald
Wouldn't a smaller controller be slow in up-dating the display ??
640x480 monochrome display = 307200 pixels; /8 = 38400 bytes.
I don't think any smaller controller can address that large of a frame
buffer memory.
And color could be 4, 8 or 16 times larger.
Something to consider.
donald
David Brown
I'm expecting to use a 32-bit controller, with a large enough external
databus (or large enough internal memory if I'm lucky) to handle the
memory needed. I'm not going to need to update the display very quickly
(it will mainly be text messages - no video or anything). I expect
something in the class of 40-100 MHz ARM7 or ColdFire v2 to be
appropriate. So "smaller and cheaper" here is relative to the 200+ MHz
devices I found in my first searches.
larwe
wrote:
> If we find something that needs some external memory, that's OK - but
> I'm hoping it will be something like a single SRAM device and the
> microcontroller's internal flash, rather than external flash and large
> fast SDRAM/DDR memories for a big processor.
Again, this is not the usual course of events. It is very unusual to
drive large framebuffers like this from SRAM. The current normal
practice in low-end devices (DVD players, PDAs, etc) is to use [SDR]
SDRAM; 100 or 133MHz bus speeds. Remember that these devices are UMA;
the bus is shared by the processor - so you need a lot of bandwidth
available to keep a 75MHz 32-bit cached core happy and well-fed with
data, plus 16bpp VGA video!
Note: There may be an ASSP that does exactly what you want. Look for
instance at ESS Technologies' media player ASSPs. They require
external SDRAM and flash of course, but such chips are available in
TSOP package, not too difficult to work with.
> The NXP part looks interesting - ARM7 is the sort of core we are
> expecting to use. Their website is so awful that I gave up trying to
:)
> find anything by myself. I hadn't thought of Cirrus Logic (we have not
> used ARM devices before, so I'm not familiar with all the suppliers),
> but I'll look into their devices later.
Very very similar part to the 79520.
> > You can also drive the panel directly in software. This isn't exactly
> > fun but it is doable. Of course you still have the RAM issue to
>
> What sort of pixel clock are needed for a typical QVGA LCD panel (if
Very roughly between 4-5MHz, but it does vary quite a lot. Of course
there is a grayscale here in terms of CPU loading - you can generate
the pixel clk from a high-speed timer, output the raw clock to an
external pin, and use an external FIFO (some number of cascaded 8-bit
or 18-bit latches) to offload the data multiple pixels at a time.
Unfortunately I have yet to find a CPU with a DMA engine that does
exactly what I would want in this regard. Some CPUs have very high
speed synchronous serial interfaces that could be used to deliver 8bpp
data to such a panel (again with an external shift register).
Stef
larwe <zwsd...@gmail.com> wrote:
>
> The Epson parts another poster mentioned exist, and they have on-chip
> framebuffer. However they certainly don't have a low pin count (QFP
> devices) and I would DEFINITELY not describe those parts as easy to
> work with! You have to glue the bus onto your micro, which is not too
> hard, but then you have to work with their semi-operable development
> system to get the chip set up for your panel. Argh. Unless things got
> a lot better since 2002, I wouldn't describe this as an easy route.
The Epson configuration utility is indeed not very user friendly. But
it's only function is to generate settings for the 50-60 registers
(s1d13706). Something you can do by yourself as well, just read the
datasheet. It only has to be done once.
In 8bpp mode the framebuffer and LUT where fairly easy to setup IIRC.
Even if you use the utility, I suggest checking every register setting
by hand. We found that the pixel clock divider will not be set up
correctly. We only discoverded this when we switched to another display
and that one didn't work and we did not understand why. It seems the
old display was happy to use the undivided 48MHz clock, while the new
display realy needed the clock to be in spec. :-) So we edited the
config file to set the pixel clock to /8 and all was well again.
suresh shenoy
wrote:
We are using a QVGA panel with ARM7 and interfacing it to a epson
controller.
Configuring epson controller might take a while, but its a good chip
which will take care of most of
the work. I heard of this new nxp chip which is all in one, but i
believe its still in the works. The PCLK we are looking
at is 6.25 MHz
Suresh M. Shenoy
Didi
> controllers for QVGA (320x240) or full VGA (640x480) displays?
People in the neighbourhood here began testing an OLED QVGA display
which comes with a controller and framebuffer memory.
The controller chip is some Samsung part IIRC, S6E63D6 ,
yes, found its datasheet at
http://www.cec-mc.ru/comp/lcd/powertip/pdf/S6E63D6.pdf
The complete display part is some C0283QGLC device, they
reported - I saw some photos - good looking results apart from
the fact that one may have to live with up to 4 bad pixels (up to
one dead colour per bad pixel, that is). The other catch may be
the lifetime, they specify 10k hours. Two guys had bought
a single piece, one had 2 bad pixels and the other had 1.
The price they mentioned was something like $70 (1 piece).
I have some more data on it on my disk, let me know if you
need some.
I have not tested this nor actually had it in my hand, I only
tell a story I have been told.
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Not Really Me
"David Brown" <da...@westcontrol.removethisbit.com> wrote in message
news:47c54d13$0$14998$8404...@news.wineasy.se...
The latest issue of EETimes had an ad from Renesas for a line of H8S and
H8SX microcontrollers that support TFT-LCD in VGA/QVGA with external SRAM.
Scott
David Brown
> On Feb 27, 9:04 am, David Brown <da...@westcontrol.removethisbit.com>
> wrote:
>
>> If we find something that needs some external memory, that's OK - but
>> I'm hoping it will be something like a single SRAM device and the
>> microcontroller's internal flash, rather than external flash and large
>> fast SDRAM/DDR memories for a big processor.
>
> Again, this is not the usual course of events. It is very unusual to
> drive large framebuffers like this from SRAM. The current normal
> practice in low-end devices (DVD players, PDAs, etc) is to use [SDR]
> SDRAM; 100 or 133MHz bus speeds. Remember that these devices are UMA;
> the bus is shared by the processor - so you need a lot of bandwidth
> available to keep a 75MHz 32-bit cached core happy and well-fed with
> data, plus 16bpp VGA video!
>
If you need the full power of the processor, such as for video decoding,
then you need fairly fast ram, and you probably need quite a bit of it.
In my case, the processor will not need to do much work - pretty much
all the external ram bandwidth will be available for the LCD. So if we
estimate a 5 MHz pixel clock for the 320x240 case, there should be no
problem using a simple low-power SRAM. At 640x480, and especially if it
is not as wide as a pixel, then we would need a faster bus.
If we have to use sdram, or if it's the cheapest and easiest solution,
then that's fine. It just seems to me that if I need 5 MHz x 16-bit
memory bandwidth for 160kB, then sdram is a bit over specified.
> Note: There may be an ASSP that does exactly what you want. Look for
> instance at ESS Technologies' media player ASSPs. They require
> external SDRAM and flash of course, but such chips are available in
> TSOP package, not too difficult to work with.
>
I just had a brief look at their site - it seems to be much more
advanced than we need. I am only planning on displaying some text (with
a few different sizes), and maybe a logo and some simple graphics.
>> The NXP part looks interesting - ARM7 is the sort of core we are
>> expecting to use. Their website is so awful that I gave up trying to
>
> :)
>
>> find anything by myself. I hadn't thought of Cirrus Logic (we have not
>> used ARM devices before, so I'm not familiar with all the suppliers),
>> but I'll look into their devices later.
>
> Very very similar part to the 79520.
>
>>> You can also drive the panel directly in software. This isn't exactly
>>> fun but it is doable. Of course you still have the RAM issue to
>> What sort of pixel clock are needed for a typical QVGA LCD panel (if
>
> Very roughly between 4-5MHz, but it does vary quite a lot. Of course
> there is a grayscale here in terms of CPU loading - you can generate
> the pixel clk from a high-speed timer, output the raw clock to an
> external pin, and use an external FIFO (some number of cascaded 8-bit
> or 18-bit latches) to offload the data multiple pixels at a time.
> Unfortunately I have yet to find a CPU with a DMA engine that does
> exactly what I would want in this regard. Some CPUs have very high
> speed synchronous serial interfaces that could be used to deliver 8bpp
> data to such a panel (again with an external shift register).
Certainly the DMA engine in the ColdFire v2 processors would need a bit
of external glue logic, but it would be possible. However, it quickly
gets to the point when it would be just as easy to use programmable
logic - a simple LCD controller would not be difficult (I made a VGA
controller in an FPGA for another application - they are not that
different).
David Brown
>> Does anyone have any recommendations for microcontrollers with LCD
>> controllers for QVGA (320x240) or full VGA (640x480) displays?
>
> which comes with a controller and framebuffer memory.
> The controller chip is some Samsung part IIRC, S6E63D6 ,
> yes, found its datasheet at
> http://www.cec-mc.ru/comp/lcd/powertip/pdf/S6E63D6.pdf
>
> The complete display part is some C0283QGLC device, they
> reported - I saw some photos - good looking results apart from
> the fact that one may have to live with up to 4 bad pixels (up to
> one dead colour per bad pixel, that is). The other catch may be
> the lifetime, they specify 10k hours. Two guys had bought
> a single piece, one had 2 bad pixels and the other had 1.
> The price they mentioned was something like $70 (1 piece).
>
> I have some more data on it on my disk, let me know if you
> need some.
> I have not tested this nor actually had it in my hand, I only
> tell a story I have been told.
>
The display type and supplier has already been picked - it's quite a lot
cheaper than the price you have there (I don't know how it compares in
quality). But perhaps Samsung also have LCD display controllers
equivalent to the Epson ones, which might be an alternative? I had a
quick look at the datasheet - it doesn't look like it is much harder or
easier to configure than the Epson parts, based on a very quick look.
Thanks for the suggestion anyway,
mvh.,
David
David Brown
I guess that's another vote for Epson!
mvh.,
David
David Brown
I've not used the Renesas microcontrollers at all - but I'll have a look.
mvh.,
David
Frank-Christian Kruegel
<da...@westcontrol.removethisbit.com> wrote:
>Does anyone have any recommendations for microcontrollers with LCD
>controllers for QVGA (320x240) or full VGA (640x480) displays?
There are QVGA TFT displays with built-in controllers.
For example:
http://www.ampire.com.tw/Eng_web/r1_am.htm
http://www.gpegint.com/tft.html
These displays only require a 3V Intel style MPU interface - D0-D7 or
D0-D15, RS, /WR, /RD, /Reset. Period. Nothing else. OK, plus LED backlight
supply and 4-wire analog interface for the ones with touch panel.
Just google for ILI9320 or ILI9325 or HX8312, and you'll find more of these.
The only problem is getting these displays in low quantities. Ordering lots
of 10k is easy.
Mit freundlichen Grüßen
Frank-Christian Krügel
Frank-Christian Kruegel
Addendum: Mouser part # 668-MTF-TQ24NN731-LB is what I mean. 36$ for Q1 and
in stock. The ILI9320 data sheet should also work for the 9325.
Don McKenzie
> I'm expecting to use a 32-bit controller, with a large enough external
> databus (or large enough internal memory if I'm lucky) to handle the
> memory needed. I'm not going to need to update the display very quickly
> (it will mainly be text messages - no video or anything). I expect
> something in the class of 40-100 MHz ARM7 or ColdFire v2 to be
> appropriate. So "smaller and cheaper" here is relative to the 200+ MHz
> devices I found in my first searches.
VGA LCD controller?
this any good to you?
http://www.dontronics-shop.com/4d-Micro-VGA-Picaso-MD1-p-16683.html
Cheers Don...
--
Don McKenzie
Affiliate Program: http://www.dontronics.com/affiliate
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
No More Damn Spam: http://www.wizard-of-oz.com
Parallax Propeller Powered .96" OLED module
http://tinyurl.com/2vr2gr
David Brown
>
>> I'm expecting to use a 32-bit controller, with a large enough external
>> databus (or large enough internal memory if I'm lucky) to handle the
>> memory needed. I'm not going to need to update the display very
>> quickly (it will mainly be text messages - no video or anything). I
>> expect something in the class of 40-100 MHz ARM7 or ColdFire v2 to be
>> appropriate. So "smaller and cheaper" here is relative to the 200+
>> MHz devices I found in my first searches.
>
> VGA LCD controller?
> this any good to you?
> http://www.dontronics-shop.com/4d-Micro-VGA-Picaso-MD1-p-16683.html
>
> Cheers Don...
>
We are going to be making a fair number of these boards - your module
might make sense for a small series, but I don't see it as a good fit
for us here. Besides, as far as I can see from your webpage it has a
VGA output, while we need to control the TFT LCD screen directly.
Thanks anyway,
David
Ulf Samuelsson
news:47c56945$0$14989$8404...@news.wineasy.se...
If you use VGA resolution, you need 36 MB / second bandwidth
from your memory system, just to do refresh.
On top of that you have overhead for CAS/RAS precharge.
The LCD refresh would eat up significant part of the bandwidth
so your ARM7 would slow down to crawl.
The AT91SAM9261 has 160 kB of memory on chip, and
there is no conflict whatsoever if you do display refresh
The AT91SAM9263 has a dual bus system so you can realisticly
use up to 800 x 600.
Both of them are of course in BGA, but you can get CPU modules
from various sources with an ARM9 with LCD support.
* www.ronetix.ch
* www.iotech.dk
* www.mechatronicbrick.dk
You could also look at the AVR32 Gateway. (ATNGW100)
Dirt cheap and good Linux support.
--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB
David Brown
That would be for a full VGA, 40 Hz refresh, 24-bit colour. We won't
need that much - I am not even sure if we are going for full VGA instead
of QVGA (at the moment, we are considering the advantages and
disadvantages of both), and we won't need that level of colour fidelity.
Also, the processor won't be doing much work anyway - all it will have
to do is write to the screen on occasion.
> The AT91SAM9261 has 160 kB of memory on chip, and
> there is no conflict whatsoever if you do display refresh
>
> The AT91SAM9263 has a dual bus system so you can realisticly
> use up to 800 x 600.
>
These two are devices I've already found, and are definitely under
consideration (I haven't used ARM's before, but we use a lot of AVR
devices from Atmel - so they are an obvious candidate as a supplier).
They are greatly overdimensioned in power and features for what we
really need - but we are still looking at possible options at the moment.
To give you an idea, the prototype system today is running with an AVR
controlling the card and a 32x140x1-bit graphics display with its own
attached LCD controller. We want to have a larger and nicer screen,
with support for colour and simple graphics. It's even possible that
with a LCD controller such as the Epson devices mentioned in this
thread, we'd use an AVR to control the screen (with an external serial
flash to hold logo bitmaps).
> Both of them are of course in BGA, but you can get CPU modules
> from various sources with an ARM9 with LCD support.
> * www.ronetix.ch
> * www.iotech.dk
> * www.mechatronicbrick.dk
>
We are not looking at ready-made modules - we have no problem designing
and producing cards using devices such as the AT91SAM9 chips. It's just
that a card using a 200-300 pin bga 200+ MHz processor and matching
memory is going to be a lot more expensive to design and produce than
one using a 140-pin TQFP 50+ MHz processor.
mvh.,
David
Ulf Samuelsson
> It's just that a card using a 200-300 pin bga 200+ MHz processor and
> matching memory is going to be a lot more expensive to design and produce
> than one using a 140-pin TQFP 50+ MHz processor.
>
If you shoot for QVGA graphic and 8 bit per pixel, you will need
75 kB for the screen, and this leaves 85 kB for the controller
in the AT91SAM9261. It is not double buffered of course...
The part will need an SPI flash to boot using AT45 flash.
Only 4 pins needed to communicate.
While the part has 217 pins, you can probably ignore the
absolute majority of the pins, simplifying the layout.
You do not need any parallel RAM memory
which would be required for the ARM7 stuff.
Fonts etc can be in the dataflash and it can
accessed using DMA (PDC) at 4 MByte/second.
Even if the part runs at 200 MHz, you can still run it at 50 MHz.
> mvh.,
>
> David
David Brown
> "David Brown" <da...@westcontrol.removethisbit.com> skrev i meddelandet
> news:47c6914b$0$15004$8404...@news.wineasy.se...
>> Ulf Samuelsson wrote:
>>> "David Brown" <da...@westcontrol.removethisbit.com> skrev i meddelandet
>>> news:47c56945$0$14989$8404...@news.wineasy.se...
>>>> donald wrote:
>>>>> David Brown wrote:
>>>>>> Does anyone have any recommendations for microcontrollers with LCD
>>>>>> controllers for QVGA (320x240) or full VGA (640x480) displays?
>>>>>>
>>>>>> I've found a few large devices (a ColdFire v3 device, and a number of
>>>>>> ARM9's from Atmel) that have LCD controllers supporting much larger
>>>>>> screens, but these are pretty big and fast microcontrollers, with
>>>>>> large pin counts and needing sizeable external memories.
>>>>>>
>>>>>> I'm hoping to find something a bit smaller and cheaper, and easier to
>>>>>> work with.
> [snip]
>> It's just that a card using a 200-300 pin bga 200+ MHz processor and
>> matching memory is going to be a lot more expensive to design and produce
>> than one using a 140-pin TQFP 50+ MHz processor.
>>
>
> If you shoot for QVGA graphic and 8 bit per pixel, you will need
> 75 kB for the screen, and this leaves 85 kB for the controller
> in the AT91SAM9261. It is not double buffered of course...
>
> The part will need an SPI flash to boot using AT45 flash.
> Only 4 pins needed to communicate.
>
> While the part has 217 pins, you can probably ignore the
> absolute majority of the pins, simplifying the layout.
> You do not need any parallel RAM memory
> which would be required for the ARM7 stuff.
>
> Fonts etc can be in the dataflash and it can
> accessed using DMA (PDC) at 4 MByte/second.
>
> Even if the part runs at 200 MHz, you can still run it at 50 MHz.
>
That's all true enough, and is certainly one way to go. We are leaning
towards the Epson controllers at the moment, however - then we can use a
microcontroller with which we are familiar (a ColdFire v2, probably).
Even simplified, using an AT91SAM9 means a fair amount of learning.
Ulf Samuelsson
news:47c74cf0$0$14998$8404...@news.wineasy.se...
Plan for a redesign in 2-3 years.
David Brown
> "David Brown" <david...@hesbynett.removethisbit.no> skrev i meddelandet
> news:47c74cf0$0$14998$8404...@news.wineasy.se...
>> Ulf Samuelsson wrote:
>>> "David Brown" <da...@westcontrol.removethisbit.com> skrev i meddelandet
>> That's all true enough, and is certainly one way to go. We are leaning
>> towards the Epson controllers at the moment, however - then we can use a
>> microcontroller with which we are familiar (a ColdFire v2, probably). Even
>> simplified, using an AT91SAM9 means a fair amount of learning.
>
> Plan for a redesign in 2-3 years.
>
Is this because you know (or can make reliable guesses) something about
the Epson parts? Or is it because you think that in a few years time
we'll want to add more features (such as video), and we'll need more
processing power?
I haven't yet contacted our suppliers and asked about the Epson parts,
but I'm certainly hoping the design will last more than a couple of years.
mvh.,
David
Ulf Samuelsson
>>> towards the Epson controllers at the moment, however - then we can use a
>>> microcontroller with which we are familiar (a ColdFire v2, probably).
>>> Even simplified, using an AT91SAM9 means a fair amount of learning.
>>
>> Plan for a redesign in 2-3 years.
>>
>
> Is this because you know (or can make reliable guesses) something about
> the Epson parts?
I hear this from customers, (and Epson distributors)
They do not expect the parts to have very long lifetime.
If you choose such a part, you should probably
discuss with the local Epson vendor, to find out
if they know if some parts are expected to have
longer lifetime than others.
Anyone else there that could validate/reject this?
> Or is it because you think that in a few years time we'll want to add
> more features (such as video), and we'll need more processing power?
>
> I haven't yet contacted our suppliers and asked about the Epson parts, but
> I'm certainly hoping the design will last more than a couple of years.
>
> mvh.,
>
> David
--
Bob
>>>> That's all true enough, and is certainly one way to go. We are leaning
>>>> towards the Epson controllers at the moment, however - then we can use a
>>>> microcontroller with which we are familiar (a ColdFire v2, probably).
>>>> Even simplified, using an AT91SAM9 means a fair amount of learning.
>>> Plan for a redesign in 2-3 years.
>>>
>> Is this because you know (or can make reliable guesses) something about
>> the Epson parts?
>
> I hear this from customers, (and Epson distributors)
> They do not expect the parts to have very long lifetime.
>
> If you choose such a part, you should probably
> discuss with the local Epson vendor, to find out
> if they know if some parts are expected to have
> longer lifetime than others.
>
> Anyone else there that could validate/reject this?
>
Reject: we've been using the same Epson LCD controller for 8 years w/ no
EOL problem. It was called the SED1352 when we spec'ed it in - Epson
changed their numbering scheme a few years back so it has a new part
number - same part.
The EOL that hurt us on that product was by Sharp - I will never spec a
Sharp LCD again. 3M (touchscreen) was another turd. We try to use
smaller, embedded-only suppliers, now. They know which side their bread
is buttered on.
Bob
David Brown
>>>> That's all true enough, and is certainly one way to go. We are leaning
>>>> towards the Epson controllers at the moment, however - then we can use a
>>>> microcontroller with which we are familiar (a ColdFire v2, probably).
>>>> Even simplified, using an AT91SAM9 means a fair amount of learning.
>>> Plan for a redesign in 2-3 years.
>>>
>> Is this because you know (or can make reliable guesses) something about
>> the Epson parts?
>
> I hear this from customers, (and Epson distributors)
> They do not expect the parts to have very long lifetime.
>
> If you choose such a part, you should probably
> discuss with the local Epson vendor, to find out
> if they know if some parts are expected to have
> longer lifetime than others.
>
> Anyone else there that could validate/reject this?
>
That's a risk with any part from any vendor - but we always make a point
of checking with our distributors (I haven't yet asked them about Epson
or other LCD controllers) about expected future availability. They are
not always omniscient, but they do a pretty good job. But it's often
useful to hear opinions, positive or negative, from around the embedded
world - hence my postings in this thread.
mvh.,
David
Didi
> Sharp LCD again. 3M (touchscreen) was another turd. We try to use
> smaller, embedded-only suppliers, now. They know which side their bread
> is buttered on.
This seems to be typical, I have had it with all display modules I
have used.
I also know how quickly products I have only considered disappear from
the market.
They seem to make a model in one batch and it lasts as long as the
stockpile
is exhausted. I am talking of VGA and higher resolution modules - this
is
where my experience is.
It is a good idea to design with a few similar display modules in
mind;
electrically they do not differ much but one must be prepared for the
mechanic changes - new bezel, screw locations, slightly different
size etc.
For designs going into small production which will live longer than
a year or so a display module change is most likely inevitable, so one
better be prepared.
I designed relying a bit too much on a particular display back in
1994.
I placed a raw of keys under the display and carefully
programmed some displayed buttons right above the keys.
Well, before I knew I had to change the display; new pixel pitch
and the mechanical correspondence buttons-display was just blown
( http://tgi-sci.com/tgi/frsa64.gif ) - fortunately to no great harm,
actually
many of these display buttons still live at the same pixel pitch
although
the keys for which tat was calculated once are long gone... :-).
Dimiter
------------------------------------------------------
Dimiter Popoff Transgalactic Instruments
http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tgi/sets/72157600228621276/
Peter Jakacki
> Does anyone have any recommendations for microcontrollers with LCD
> controllers for QVGA (320x240) or full VGA (640x480) displays?
>
> I've found a few large devices (a ColdFire v3 device, and a number of
> ARM9's from Atmel) that have LCD controllers supporting much larger
> screens, but these are pretty big and fast microcontrollers, with large
> pin counts and needing sizeable external memories.
>
> I'm hoping to find something a bit smaller and cheaper, and easier to
> work with.
>
> exists these days.
ARM7? NXP?
If you are not too fussy about color depth you can run it all from the
internal ram of an LPC2148 without any external chips.
Check out http://www.pbjtech.com/ for some screenshots
and http://www.pbjtech.com/downloads/IVOS%20release.zip for source code
to roll your own.
*Peter*
Trev16v
an ARM-based device with a 320*240 TFT. It is a hobby project but I do aim
to produce a number of them if all goes well, so I need a cheap design and
I don't want to use anyone else's modules. Having spent many hours looking
at ARM devices from Sharp, NXP, Atmel and so on with integrated controllers
and ended up rejecting all of them either because they're BGA, or because I
can't get the devices easily or have fear of them becoming obsolete
(especially Sharp) or various other reasons, I have decided to fall back
on the old faithful solution which is to use an Epson controller together
with an ARM that has an EMI.
In fact my prototype at the moment is an STR710FZ2T6 together with not an
EPSON device, but instead a Solomon SSD1906. I don't think that anyone has
mentioned the Soloman parts yet but they appear to be the Epson parts that
have been rebranded and repackaged. Maybe someone can tell me more about
this.
I went for the Solomon device because it's easy to get hold of in the UK
to make a prototype. Rapid Electronics and RS over here actually stock it.
To get an EPSON S1D device I'd have to make an expensive order from Digikey
in the US.
The STR710, SSD1906, plus the flash and RAM is quite a nice cheap solution
I think.
I have personally already worked with the EPSON S1D devices in the past,
by the way. Several years ago where I used to work I did a design using
the S1D13705. I found it really easy to use. I didn't use any of EPSON's
software. I just used the datasheet and wrote my own routines and so on.
That design used a PIC18F8720! I guess the slow response and blurryness of
the STN panel we used sort of disguised how slow the graphics were :-) That
product is still being sold by the company, so maybe I could try to sell
them an improved ARM version...
Now for a question:
For those who have already used an EPSON or similar device with an ARM
controller, what kind of speed of graphics can one achieve assuming, say,
anything from a 320*240 to a 480*640 VGA panel? Assuming an ARM7 and
S1D13705 or similar, can anything near to streaming video be achieved?
Cheers
Trev
larwe
> anything from a 320*240 to a 480*640 VGA panel? Assuming an ARM7 and
> S1D13705 or similar, can anything near to streaming video be achieved?
A datapoint: 74MHz ARM with no hardware MPEG acceleration features,
Icache/Dcache enabled, can do about 10fps (no audio) on a 320x240
MPEG-1 stream to a 32-bit-wide UMA video framebuffer operating at full
processor bus speed.
With your hardware I would say you'll be very lucky to do QCIF.
Ulf Samuelsson
news:JaadnU4-PN_XsFba...@giganews.com...
> This is an interesting discussion because I'm also trying to put together
> an ARM-based device with a 320*240 TFT. It is a hobby project but I do aim
> to produce a number of them if all goes well, so I need a cheap design and
> I don't want to use anyone else's modules. Having spent many hours looking
> at ARM devices from Sharp, NXP, Atmel and so on with integrated
> controllers
> and ended up rejecting all of them either because they're BGA, or because
> I
> can't get the devices easily or have fear of them becoming obsolete
> (especially Sharp) or various other reasons, I have decided to fall back
> on the old faithful solution which is to use an Epson controller together
> with an ARM that has an EMI.
>
> In fact my prototype at the moment is an STR710FZ2T6 together with not an
> EPSON device, but instead a Solomon SSD1906. I don't think that anyone has
> mentioned the Soloman parts yet but they appear to be the Epson parts that
> have been rebranded and repackaged. Maybe someone can tell me more about
> this.
Why not an AT91SAM9260?
TQFP and 200 MHz...
Should leave an ARM7 in the dust...
>
> I went for the Solomon device because it's easy to get hold of in the UK
> to make a prototype. Rapid Electronics and RS over here actually stock it.
> To get an EPSON S1D device I'd have to make an expensive order from
> Digikey
> in the US.
>
> The STR710, SSD1906, plus the flash and RAM is quite a nice cheap solution
> I think.
>
> I have personally already worked with the EPSON S1D devices in the past,
> by the way. Several years ago where I used to work I did a design using
> the S1D13705. I found it really easy to use. I didn't use any of EPSON's
> software. I just used the datasheet and wrote my own routines and so on.
> That design used a PIC18F8720! I guess the slow response and blurryness of
> the STN panel we used sort of disguised how slow the graphics were :-)
> That
> product is still being sold by the company, so maybe I could try to sell
> them an improved ARM version...
>
> Now for a question:
>
> For those who have already used an EPSON or similar device with an ARM
> controller, what kind of speed of graphics can one achieve assuming, say,
> anything from a 320*240 to a 480*640 VGA panel? Assuming an ARM7 and
> S1D13705 or similar, can anything near to streaming video be achieved?
>
Not a chance...
Not even an ARM9 is particularily good.
Some people may have noted the new crop of ARM9/ARM11 with
Video accelerators.
An AVR32 can do QVGA in S/W, but you can only get them in BGA package.
There is a cheap board, the AT91NQW100, but that only has
a 16 bit SDRAM so performance is a little thinner.
On the other hand, the AVR32 can do QVGA video at 75 MHz
with a 32 bit bus, and IIRC, the NGW100 runs at 150 MHz.
> Cheers
>
> Trev
bigredhdl
>controllers for QVGA (320x240) or full VGA (640x480) displays?
>
>I've found a few large devices (a ColdFire v3 device, and a number of
>ARM9's from Atmel) that have LCD controllers supporting much larger
>screens, but these are pretty big and fast microcontrollers, with large
>pin counts and needing sizeable external memories.
>
>I'm hoping to find something a bit smaller and cheaper, and easier to
>work with.
>
>Stand-alone LCD controllers would be an alternative, if such a thing
>exists these days.
>
Does anyone have recommendations if the display is monochrome? Or is the
Epson part still a good one for that? I was thinking that Microchip's
graphics library might be good to use for my application, but it only
supports certain display controllers as well as only QVGA. Has anyone
adapted this for higher resolution or added a controller?
John Devereux
There is the LH79520 and family, although I guess that is still fairly
large (ARM7, external SDRAM & flash, 208 pin QFP).
I wonder if it is possible to bit-bang a monochrome QVGA? Should be
possible if it is just the row the row clocking that needs to be
accurately timed (and not each pixel).
--
John Devereux
Ulf Samuelsson
news:87ve3io...@cordelia.devereux.me.uk...
> "bigredhdl" <char...@cetac.com> writes:
>
>>>Does anyone have any recommendations for microcontrollers with LCD
>>>controllers for QVGA (320x240) or full VGA (640x480) displays?
>>>
>>>I've found a few large devices (a ColdFire v3 device, and a number of
>>>ARM9's from Atmel) that have LCD controllers supporting much larger
>>>screens, but these are pretty big and fast microcontrollers, with large
>>>pin counts and needing sizeable external memories.
>>>
>>>I'm hoping to find something a bit smaller and cheaper, and easier to
>>>work with.
>>>
>>>Stand-alone LCD controllers would be an alternative, if such a thing
>>>exists these days.
>>>
>>
>> Does anyone have recommendations if the display is monochrome?
[snip]
> I wonder if it is possible to bit-bang a monochrome QVGA? Should be
> possible if it is just the row the row clocking that needs to be
> accurately timed (and not each pixel).
>
> --
>
> John Devereux
On an AT91SAM7SE or AT32UC3A you could use an SSC
in loopback mode to read from internal RAM , send it through the SSC
and then receive it back and write it to the LCD.
320 x 240 = 9600 bytes, so you can fit into the internal SRAM.
At 60 Hz, this is is 576 kB/s.
Stevek34
What was the outcome of this? I am in a similar situation, having to drive
a QVGA with colour depth of 8bit. I am currently looking at the new
Coldfire V2 MCF52277 with integrated LCD controler.
Does anyone have any experience with this device?
donald
>>>>> Does anyone have any recommendations for microcontrollers with LCD
>>>>> controllers for QVGA (320x240) or full VGA (640x480) displays?
>>>>>
>>>>> exists these days.
>>>>> Does anyone have recommendations if the display is monochrome?
Epson replaced their SED1335 controller family with S1D13700F02.
Digikey carries them at:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=S1D13700F02A100-ND
This chip is 64-pin TQFP w/built in 32K memory.
Google S1D13700 for app notes and sample code.
donald
Ulf Samuelsson
"Stevek34" <steve....@huntleigh-diagnostics.co.uk> skrev i meddelandet
news:k4mdnXL95Jd8V2DV...@giganews.com...
There are plenty of devices capable of driving a QVGA @ 8 bpp.
The AT91SAM9261 has enough RAM for a double buffered
framebuffer, drawing in internal RAM is much faster than drawing
in an external SRAM.
If you need Ethernet, then the AT91SAM9263 would be a good choice.
--
--
Best Regards,
Ulf Samuelsson
u...@a-t-m-e-l.com
This message is intended to be my own personal view and it
may or may not be shared by my employer Atmel Nordic AB
tns1
>> "John Devereux" <jdRE...@THISdevereux.me.uk> skrev i meddelandet
>> news:87ve3io...@cordelia.devereux.me.uk...
>>> "bigredhdl" <char...@cetac.com> writes:
>>>
>>>>> Does anyone have any recommendations for microcontrollers with LCD
>>>>> controllers for QVGA (320x240) or full VGA (640x480) displays?
>>>>>
The LPC247x supports STN, TFT at QVGA possibly larger. For monochrome it
would take away only a few % of the total BW. There are app notes and a
discussion forum at NXP.