LM3S9B96 evaluation board comes with a 320 x 240 (QVGA resolution) LCD display. Can the processor support higher resolution displays, SVGA (800 x 600) or XGA (1024 x 768) or WXGA (1024 x 720) ??
Venkat RamananCan the processor support higher resolution displays
Not likely - in fact doubtful that the uC can support even lowly QVGA @ 16-24 bpp @ 30+ Hz. Suspect that the display on Eval board has "in-built" data-bus lcd controller. SSD1963 has "won many sockets" for control of normal Lcds & TFTs - up to 800x480 pixel resolution. Features both an 8 bit and 16 bit data bus (plus adr & strobes) for interface to your MCU. Beyond this you can consider FPGA + screen buffer or ARM MCU w/advanced TFT Controller in-built. (on our Stellaris wish-list)
If you can find a higher resolution panel with an integrated frame buffer and display controller then you should be able to attach it to a 9B96 assuming it has an interface that is compatible with the EPI or some other 9B96 communication peripheral. Although we don't ship anything higher resolution than QVGA, I have a Kentec K90DWN2 800x480 panel sitting on my desk that should work (I just haven't found the time to play with it yet!).
You are unlikely to be able to use a display of this size for video-like refresh rates from a Stellaris but it should be adequate for low refresh, HMI applications, I expect (with apologies to CB1 for contradicting him again!).
[Edit: It looks like I'm actually agreeing with CB1 after all. This display has an SSD1963 controller and integrated frame buffer.]
For those interested - here's the basis for my suggestion of "stand-alone" Lcd Controller: Recall - poster specifically asked, "Can the processor support higher resolution displays?" This strongly suggests that he/she seeks to employ the MCU as "display controller" - despite protest I stand by my earlier recital... (No - not a good idea) Here's why:
For QVGA TFT - 320 * 240 = 76,800 pixels. If we allow 16 bpp the required display "Frame Buffer" is 153,600 bytes. At 24 bpp - 230,400 bytes. Both far exceed the SRAM capacity of any Stellaris. Strike ONE.
To realize such a design w/Stellaris doing this repetitive "grunt-work" - every single SRAM byte must be read at a minimum of 30 Hz - many displays will require higher rates to preclude flicker. As no Stellaris has this capacity - one is forced to use physically larger (and more expensive) external bus MCUs. And then procure, place & connect the necessary SRAM. (makes great sense - huh?) Strike TWO.
This rather large (by MCU standards) SRAM must be constantly read - sent to the display - and optionally written when the screen image is changed. While this "might" be w/in the capability of a Stellaris (or other - similar ARM MCU) it is far from their "Sweet Spot" - and a particularly poor use of the wondrous MCU resource. And - to be kind to Dave W. - we haven't even "touched" on the issue of Frame Buffer read-write contention during screen updates... Strike THREE.
Long live Stellaris - for applications which are truly "MCU appropriate" - which is NOT direct TFT display control! Huge numbers of Lcd & TFT controllers exist just for these reasons - looking outside the "MCU Prism" may be justification for non corporate posters to present their opinions - especially when experience, logic, and a broader perspective aids insight!... Again - this is not a "knock" upon Stellaris - just a serious mismatch of application.
I'd provide my own, "green tick" (as opposed to the earlier "ticked" TI response) but rely on the fairness of others for such reward... BTW - SSD1963 includes an enormous, internal Frame Buffer - yielding unmatchable cost, size & use benefits...
Well put - I am 100% in agreement with you here.
@Dave - Thank you - sometimes even blind squirrel stumbles across a walnut! (5+ years Engineering school + UCLA Law + founding/taking display firm public not all for naught) Sometimes (often) the business case for a competing solution must be examined - SSD1963 is over-whelming winner here...
That said - the support you've provided me, hundreds (thousands) of others wrt famed "Stellaris Graphic library" deserves mention/emphasis. While current Stellaris may not be "stand-alone" suitable for direct drive/control of large graphic displays - the Stellaris Graphic Library surely is! As Dave has often said - much easier to "tweak" the Display Driver software so that most any display can operate in conjunction with the Stellaris Graphic Library.
@cb_1 & @Dave Thanks for your Reply. We have started looking for other options for the display controller.
@cb_1: From what you have written here, i unerstand that the Stellaris Graphics Library can be used, with some tweaks, on other platfroms also. (C6000 or AM17x). Is that right?
@Venkat: While I have some ideas in this regard (Stellaris Graphics Lib extension) - this really is Dave's area and I defer... (BTW - thanks for your green tick - appreciation is always welcome)
Venkat,
The StellarisWare license agreement allows you to use any of the code on any TI device. I know that the Sitara (AM17x) people ship a port of our graphics library with their software but I don't know about C6000. That said, there's nothing that's particularly tied to the Stellaris hardware in grlib so I would imagine that porting it yourself wouldn't be too tricky if there isn't a port already provided.
Thanks Dave and cb1 for your replies..