Microcontroller with QVGA or VGA LCD controller

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.

  • formatting link
  • formatting link
  • formatting link

You could also look at the AVR32 Gateway. (ATNGW100) Dirt cheap and good Linux support.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson
Loading thread data ...

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.

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

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

Reply to
David Brown

[snip]

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.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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.

Reply to
David Brown

Plan for a redesign in 2-3 years.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

Reply to
David Brown

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?

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

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

Reply to
Bob

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

Reply to
David Brown

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 (
formatting link
) - 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

formatting link

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

formatting link

Bob wrote:

Reply to
Didi

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

formatting link
for some screenshots and
formatting link
for source code to roll your own.

*Peter*
Reply to
Peter Jakacki

This is an interesting discussion because I'm also trying to put togethe an ARM-based device with a 320*240 TFT. It is a hobby project but I do ai to produce a number of them if all goes well, so I need a cheap design an I don't want to use anyone else's modules. Having spent many hours lookin at ARM devices from Sharp, NXP, Atmel and so on with integrated controller and ended up rejecting all of them either because they're BGA, or because can't get the devices easily or have fear of them becoming obsolet (especially Sharp) or various other reasons, I have decided to fall bac on the old faithful solution which is to use an Epson controller togethe with an ARM that has an EMI.

In fact my prototype at the moment is an STR710FZ2T6 together with not a EPSON device, but instead a Solomon SSD1906. I don't think that anyone ha mentioned the Soloman parts yet but they appear to be the Epson parts tha have been rebranded and repackaged. Maybe someone can tell me more abou this.

I went for the Solomon device because it's easy to get hold of in the U 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 Digike in the US.

The STR710, SSD1906, plus the flash and RAM is quite a nice cheap solutio 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 usin the S1D13705. I found it really easy to use. I didn't use any of EPSON' 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 o the STN panel we used sort of disguised how slow the graphics were :-) Tha product is still being sold by the company, so maybe I could try to sel them an improved ARM version...

Now for a question:

For those who have already used an EPSON or similar device with an AR 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 an S1D13705 or similar, can anything near to streaming video be achieved?

Cheers

Trev

Reply to
Trev16v

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.

Reply to
larwe

"Trev16v" skrev i meddelandet news:JaadnU4-PN_XsFbanZ2dnUVZ snipped-for-privacy@giganews.com...

Why not an AT91SAM9260? TQFP and 200 MHz... Should leave an ARM7 in the dust...

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.

--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

Does anyone have recommendations if the display is monochrome? Or is th Epson part still a good one for that? I was thinking that Microchip' graphics library might be good to use for my application, but it onl supports certain display controllers as well as only QVGA. Has anyon adapted this for higher resolution or added a controller?

Reply to
bigredhdl

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
Reply to
John Devereux

[snip]

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.
--
Best Regards,
Ulf Samuelsson
 Click to see the full signature
Reply to
Ulf Samuelsson

large

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?

Reply to
Stevek34

Epson replaced their SED1335 controller family with S1D13700F02.

Digikey carries them at:

formatting link
?name=S1D13700F02A100-ND

This chip is 64-pin TQFP w/built in 32K memory.

Google S1D13700 for app notes and sample code.

donald

Reply to
donald

"Stevek34" skrev i meddelandet news:k4mdnXL95Jd8V2DVnZ2dnUVZ snipped-for-privacy@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,
 Click to see the full signature
Reply to
Ulf Samuelsson

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.