Forums

Others will address use of TI display kits - their modifications (if any) and time/effort/cost required.

Different tack is display resolution - while QVGA (320x240) is quite adequate @ 3.5" (and under) it appears "pixelated" when blown up to your desired 5.7."  Have been in display biz - most serious clients much prefer VGA (640x480) when display exceeds 5."  And this complicates your life as the control chips which support this higher resolution have not yet found their way into StellarisWare - or TI display kits commonly available w/in Stellaris community. 

From a business perspective - 4.3" TFT (480x272) is much more "sweet spot" than 5.7 - especially VGA 5.7!  (you'll realize very nice cost saving with 4.3) 

Controller IC many serious developers/firms have chosen is SSD1963 - supports resolutions to 800x480.  TI has not yet integrated the required display driver but TI friend Dave Wilson lurks here - surely will "come aboard" aid/assist.  SSD1963 supports either 8 or 16 bit MCU data bus (double up ports when using "basic" Stellaris MCU - strobe "write" after 16 bit (2 ports, Stellaris) data is assembled.)

You/your clients really need to see 5.7" QVGA and VGA side by side - to make best decision.  (of course contrast, view angle, backlight brightness should all be equal to optimize this comparison)  This critical "side by side" observation - performed w/ near identical data/images on each screen - is sorely underserved by most display vendors..

Hi cb1,

Thanks for your comments. We will look into the various resolution LCDs you mentioned above. If we find that 5.7" QVGA (320x240) screen is acceptable for our application, then can we use Stellaris® Intelligent Display Reference Design Kits as the baseline of my project? Does the LCD vendor for the 3.5" screen used in the kits also provide a 5.7" LCD with QVGA resolution?

Regards.

Lin

A qualified "yes" provided that:

a) same Lcd control IC emplaced - 3.5 and 5.7" displays

b) same Lcd connector emplaced (pinout, pitch, type)

c) backlight voltage & current demands likely will be higher w/5.7" and pinout scheme may differ

(there may be more - these are the most major - imho)

Don't think I've yet convinced you of the numerous advantages due to higher VGA resolution: 

a) You are most likely to "import" photos and existing images for use in your application.  VGA (640x480) resolution will really shine here - so much easier to maintain image quality when you aren't forced to "degrade" the reference image/photo so that it will "almost" fit upon pixel-starved QVGA.  (you throw away 3/4 of the image quality - so that you can "fit" to now out-moded QVGA) 

b) VGA accommodates substantially more Text rows & columns - enabling you to far better exploit scaled fonts so that your screens really can emphasize and "pop!"

c) Observe - see any QVGA tablets?  Any QVGA GPS units (beyond surplus/unsellable)?  Even top half cell-phones exceed - sometimes far exceed.  (try 960x480 - and that on far smaller than 5.7" diagonal you propose)

d) Shortly you will be pushed into using higher pixel displays - none currently supported by existing StellarisWare.  (GRL tad long in the tooth - as regards display choice)  By choosing an SSD1963 Controller you can accommodate high-pixel TFTs of 3.5, 5, 5.7, 6.4, and 7.0" (at up to 800x480 pixels)  Thus - with a single development effort you will have likely solved many future needs -  and avoid the likely 5.7" QVGA EOL "around the corner!"

Hi cb1,

Thanks again for your advice. I will definitly look into this ssd1963 controller and higher resolution displays. But other than display, I have other functions to do on the board, such as Ethernet and ADC/DAC monitoring. The TI eval board gives me all those from one chip.

Could somebody from TI provide me some information on the work load involved if I wan to change the display to 5.7" with or without a LCD display controller?

Thanks.

Lin

Aside from reworking your applications to take account of any difference in the resolution of your new display compared to the previous one and to rename the display driver you are using, there are two main jobs you will need to do. Both of these are easy assuming you have some sample code that will initialize the registers in your display controller and let you access its frame buffer.

1. You will need to write a new display driver. This is very easy (the last one I wrote took a morning) and involves implementing a few very basic functions to initialize the display, plot a point in a given color, draw horizontal and vertical lines and copy a line of pixels from memory to the display. You can find more details on this in this appnote.
2. Assuming your new display has a resistive touchscreen overlay, you will need to produce a version of the touchscreen driver that is correctly calibrated for the new display. You can only do this once your display driver is up and running since you will need to port and run the "calibrate" example app on your new display to get the required parameters for the touchscreen driver to use. If you support the ability to rotate the display as we do in the existing IDM display drivers (look for PORTRAIT, LANDSCAPE, PORTRAIT_FLIP and LANDSCAPE_FLIP in the code), you will need to run the "calibrate" application 4 times, once with each of the possible display orientation labels defined and gather 4 sets of parameters. If you support only 1 display orientation, then you only need one set of parameters.
   When you have the parameters, plug them into the touchscreen driver (touch.c) and you should be good to go. The only parameter you may need to tune that is not handled by the calibrate application is the basic touch detection threshold. This is the ADC reading below which it is assumed that the screen is not being touched. In the touchscreen drivers for IDM and IDM-L35 it is hardcoded to 100 but if you look at the driver for the dk-lm3s9b96 you will find it parameterized as TOUCH_MIN since it varies from design to design.
   To determine TOUCH_MIN, run calibrate in a debugger with a breakpoint on TouchScreenDebouncer and look at the g_sTouchX and g_sTouchY values when you are not touching the screen and also when you are touching each corner. From this, you can determine a safe value of TOUCH_MIN (larger than the g_sTouchX and g_sTouchY values you see when not touching the screen but smaller than any value you see when touching anywhere on the display) for your board and display.

I hope this is useful. Post again if you have any problems and I'll see if I can help out.

@Dave Wilson - like clockwork - poster/others, this reporter thank you.

Wonderful coverage of the "software side" of this screen change.  To complete poster's request - would you agree and/or bless my earlier comments re: major hardware considerations/changes - in essence:

a) connection and or cable changes required to mate TI Eval board to new (larger) display

b) likely changed (increased) backlight (b/l) voltage and current requirements for new (larger) display - may require a re-engineered b/l drive and different connections

Thank you, DW...

Although I'm not really qualified to comment on the current requirements or voltage changes needed to handle different backlights, these are definitely things to consider before trying to bolt a new display onto an existing IDM board (these are hardware questions, I'm a software guy :-) ).

One other thing that hasn't been mentioned in the thread so far is probably pretty important when considering the resolution. Remember that, as the screen resolution increases, the size of the various graphical assets (fonts and images) you will need will increase too. Unless you are planning to use the SDCard for storing these (which is perfectly feasible but, obviously, makes the software more complex) be very careful that you don't find yourself in a position where you don't have sufficient flash on the IDM to store the resources you need!

Display upgrades - as requested by poster - breathe new life into TI Eval Kit Sales.  Unfortunately both hardware and software are likely to demand accommodation.  Beyond just the backlight - in the majority of cases we've seen/encountered - unchanged (pin for pin) compatibility is a rarity.  Even world-class software cannot succeed with a mis-wired board to display data/signal inter-connect. 

Our group never liked (nor followed) the LMI command decision to place font image data w/in Stellaris internal memory.   In the olde days - we always dedicated external memory for such tasks.  Further - with images & photos becoming more and more prominent (i.e. see Facebook's recent acquisition) any chance of "kitchen sink" fitting fully w/in Stellaris is doomed...  (at least until new 1MB and beyond are formally announced - and even that may not be enough! - and is a poor use of resource...) 

New ways ain't always better!   (as I look @ 50+ year old print photo - yet to be lost when CD "rots" and/or hard drive fails...)

FYI, the Stellaris graphics library now supports access to fonts in external memory or file systems via the Font Wrapper feature.

Appreciate your follow-up as well.  If I were you - and commited to new board design - I'd include the SSD1963 pcb footprint and Stellaris to SSD interconnects.  You do not have to always "fit/place" SSD1963 - but having it present/accounted for will save you yet another board-spin down the line.  (when your clients reject "sparse pixel solutions" or demand still larger screen or OLED etc.  Pressure from the consumer side - with the massive penetration of Tablets - severely impales under-pixeled QVGA for any serious color-graphic application...)

Believe you'll do well to anticipate - and provide for much increased Led backlight (b/l) power demanded by larger displays, too.  Suspect you may encounter up to 10 series connected, white Leds or 2, 3 parallel paths - composed of 4-6 series Leds - each.  Point is - you may have to provide up to 40VDC at currents which may reach 100mA.  (not that voltage @ that current - parallel paths will consume more current - series paths will require higher voltage)  Stock b/l circuit on LMI/TI boards is not up to this task...  (note: some "forward-looking, inside info" in play as regards to pending/future Led b/l...)

One method would include an edge connector to best mate with your (perhaps) top 2 chosen displays.  Via selective placement of "programming" 06-03, 0-ohm Rs, you can "reconfigure" the connector pinouts per board build.  (hope here is that maximum 25-30% of pinout requires change)   Yet another technique is to route all possible, "display required signals" to an edge connector - and then design a compact "configure to specific display" 2nd board which, "plugs-in." 

Display field is dynamic - change is constant - "locking in" on any one display most always will cost you in the long run...  Best advice - don't limit yourself (i.e. include SSD1963 or similar) and be prepared for display change(s) w/in the life-cycle of your product...  (note - receive no benefit/reward from SSD maker)