MCU w/ integrated graphics LCD controller suggestions?

"Bob" skrev i meddelandet news: snipped-for-privacy@mid.individual.net...

You need a sync serial peripheral which can transfer a continous bitstream of data, preferably without user intervention and then you need to have a number of timers. The AT91SAM7S/X/A3 has the SSC (Synchronous Serial Controller) which is connected to a double buffered DMA capable of sending up to 64 kB/transfer. The SSC clock can be driven by an external clock signal, which you can generate by one of the timers. This reduces the number of interrupts to one per frame. With a 64 kB part, you can double buffer.

Note that you are only shifting out one bit at a time, so you may need external H/W to generate two bit, or you use the SAM7A3, which has 2 x SSCs but then you have to divide the memory into planes, each handling one bit. This only has 32 kB of SRAM, so you cannot have more than 2 bits per pixel.

Other timers can be used to generate the other signals needed by the LCD. Since 19200 * 8 > 65535, you have to prescale the timers before you use them.

You are likely to be better off getting a CPU module with an AT91SAM9261 which supports QVGA with up to 16 bits per pixel in the internal memory, (It is in BGA, so you dont like the bare chip)

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

Why rule out BGA? With quantities over 1k/year, I suspect you have them assembled somewhere. If they can't handle BGA, look a bit further.

I myself try to stay away from BGA when possible as it makes debugging harder. But I don't rule it out upfront if that severely limits my chip choices. (We so far have not designed a board with BGA, but it probably won't be long before we will require it)

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

I second Ulf's suggestion to look at driving the LCD "manually" but of course other parts beside Atmel's can achieve this - ST, Philips (NXP), etc.

Thanks Ulf, The LCD actually has 4 data bits. Doesn't the glue logic to run it from less than 4 SPI channels gets a little ugly? Also, I believe the gray scale is done with PWM so doing it manually would mean planes even for 2 bit/pixel :-(

OTOH, poking around the Atmel site I see the AT91SAM7SE256 (256k flash,

32kSRAM internal and a full 16 bit wide by 20+bit tall external bus) with an Epson S1D13706 (80k graphics ram) hanging on the side will do the job nicely for

Actually, we assemble everything here in Sunnyvale, CA, USA. Old school, I know ;-)

Yup. We're looking over that BGA cliff, too. Soon, now... real soon.

Bob

hmmm. Or maybe something that's designed to output video - like a BlackFin PPI port?

Bob

I would DEFINITELY not characterize the BlackFin devices as "a modest MCU" ! I'd be looking at a low to midrange 16/32 part, hence the ARMy suggestions.

no, I don't think of the BF as a modest part either (and it doesn't qualify for my single chip solution w/o BGA either). All I meant is that a BF PPI would be physically able to clock out the pixels on-time.

The bit rate required to drive a 320x240 2bpp at 50Hz refresh is

3.84Mbit/sec (unless I totally dicked the arithmetic ;-/) and it can't have a lot of jitter. How would you "manually" do that without some dedicated hardware like 4xSSP, PPI, etc?

Bob

There are a bunch of ways of doing it. Even a humble 8-bit micro like the ATmega128L can pump data out the SPI port at 8Mbit/sec if you use fosc/2 as the clock source and a master clock of 16MHz.

More exotic solutions include latching 8 or 16 bits of data into an external flipflop and interrupting the micro in time to reload the latch (or double buffering). A little external discrete logic - or a PAL - will do this fine.

I did it with ATMega@16.384MHz for the sake of demonstration. Just a loop which outputs a fixed picture. Of course, it barely can be used for anything practical. Why can't you just put the external LCD controller on the board?

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Right. If I didn't have to respond as a slave to another processor, then blasting out the raw pixels in a tight foreground loop would be OK. I could do what little *other* processing I needed between frames, I guess.

I can. In fact, that's the route I'm leaning toward at the moment (see my response to Ulf). My goal isn't to try to make fire by banging two rocks together. I'm just curious to see if there's a single chip solution. It turns out that a part from NXP (to be released Q4 2007 and I don't have the p/n here - LPC something x78) would do it in non-BGA (208 pin LQFP on 0.5mm pitch though :o| ).

Bob

Maybe I wasn't clear: that's 3.84Mb/s on *four* simultaneous data lines to the LCD while toggling the pixel clock line. Ok, I can imagine sitting in a cycle-timed loop spitting out a frame one nibble at a time, but doesn't that mean leaving interrupts turned off for at least a whole line (maybe frame)? I must confess: I don't know a "whole bunch of ways" (one, even :-) to do it without MCU hardware support (e.g. timer driven DMA to an I/O port). What ways are you referring to?

Bob

I wonder, does this type of LCD (STN?) actually need "cycle-accurate" timing for every pixel? Perhaps you have arbitrary pixel timing provided the line pulses are consistent. Have to try that sometime.

--

John Devereux

What? No it isn't. If you have a 320x240 [mono] STN LCD that uses a 4- bit data interface, data is sent 4 pixels at a time. (Grayscales are achieved through FRM, nota bene) Your data requirement is 3.84Mbps out a single serial line, 960Knibbles/sec to the LCD. This can be achieved by:

- configure SPI peripheral as master

- route MOSI to a 4-bit serial-to-parallel shift register, outputs of which go to a 4-bit latch.

- route SCK to the shift register, and SCK/4 to the latch and to the LCD's data clock line.

Actually the data rate is a bit higher than that because each line has a front and back porch of finite size, during which time there is no data transfer.

Thanks, FRM is what I meant when I called it PWM. A gray pixel is on for x out of N frames and off for the remainder. Thanks for giving me the correct term.

OK. I get it now. I didn't see how to shove the byte into the SPI tx register without looping and doing _nothing_ else... Now, if the MCU can DMA to the SPI, everything is easy.

To expand on what you said: SPI into a serial-to-parallel and combine each 2 bits in the output latch with the two frame count bits (current frame count 0 to 3 for 2 bit monochrome) to get the FRM lookup value that goes into the LCD panel.

Since I really only need 3 colors (white, black, and one gray) I could use the extra color to generate the porches by padding my image rows and gating the pixel clock off. The DMA can handle an entire frame and leave the processor alone until the DMA terminate interrupt fires at 70Hz. Even if I can't get the porches to run automatically from the data, the interrupt interval for each row is around 30uS so I'll have a *little* time to get other things done. (70Hz frame * 240 rows = 33.6kHz)

And, you're right: all the above fits in a tiny PAL!

Now I just need a micro that can DMA to the SPI.

To recap my minimum requirements:

1) 32kSRAM internal 2) 128kFlash internal 3) DMA over SPI 4) at least one other serial ifc to talk to the host (SPI or UART) - DMA nice but not required. 5) non-BGA

I've found the AT91SAM7 family can do it (does that mean any ARM7 can do it?). I don't need all the other hooha that comes with the AT91 family but at $10, I'm OK with letting it go to waste ;-) Any other families I should be looking at to get item #3?

Thanks again, Bob

3 colours out of 2 bits per pixel should be doable, but beware the display behaviour during frame rate control.

Many years ago (1993-4) I designed a VGA sized, highly sophisticated LCD controller (had one character and two graphics layers, switchable on a per character box - 8x12 pixels - basis) which did 2 bits per pixel frame rate control. It worked fine, but the first display - a Hitachi, 640x480 being pretty much the top resolution at that time - hardly tolerated the frame rate control. It worked fine at 0 and 3 and was nearly usable at 1 - over a narrow interval of the bias voltage - and totally unusable at 2, did full height black vertical stripes even if you did a single pixel of colour 2 (IIRC 1 was pixel on every third frame while 2 was on every other frame). Several years later - around 1998 - I changed the display with a newer model - managed to get a Sharp at that time - which was much better but the issues were still to be recognized - and I don't remember if it was usable at 2 (and it would be too much of a hassle to dig out the old Nukeman and turn it on to try now :-). I don't know what has happened to the mono double twisted whatever kind of displays I used then; may be they are better and may be they have not changed since 1998. I switched to TFT then, end of such issues. BTW, QVGA TFT displays are not that expensive, you can still do just 2 bpp and live a much happier life if the product can afford the TFT :-).

Dimiter

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

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

Look at the Atmel uC, that's one of their strengths.

See Atmel for PLDs too. 22V10, and their new ATF1502BE, if you need more muscle.

-ie you could do some raster timing with the ATF1520BE.

-jg

Thanks Jim, That's just what I was looking for: a TQFP48 or 64 with DMA on _all_ the peripherals. Though, it's curious that I can't find any distributors for it. The Atmel site lists Arrow, Avnet, Digikey, Mouser and some smaller outfits, but none of them list P/A info for the AT32UC3Bxxxx stuff. I guess I'll have to go "analog" on this one (pick up the phone ;-) ) I did see one bit of press that mentioned one of these parts at ~$5 in 10k quantities. Nice!

Bob

That price is nothing special. Most 32 bit processors can reach that price if similarly equipped with memory, peripherals and pin count. I'm not familiar in detail with that device, but many ARM chips from Atmel and Philips as well as others are much below $5 in those quantities.

You will find that the AT91SAM7S series parts are much more available and a great number more people are already using them. As a comparison point, check the Yahoo groups for the AT91SAM and the AVR32. The SAM group has over 1000 members and gets around 100 messages a month. The AVR32 groups (two of them) have less than 50 members and have had a total of 9 messages in the last year. The AT91SAM7 parts are available, largely from stock, from Digikey and Mouser not to mention the other distis. You found out how available the AVR32 is.

Which family do you want to work with?