Drive a 4x16 character LCD with TMS320F28335

Hi Igor,

I'm too trying to interface 16x2 LCD with TMS320F28335. Currently I'm modifying another controllers driver... If there's a ready-made driver available let me know!

:)

Regards,

Gautam

Igor/Gautam,

What is the interface to the LCD? Parallel, serial?

Brian

Such text-only Lcds are almost always HD44780 (or compatible) parallel based.  And this is well detailed across the net.

Either 4 or 8 bit parallel data interface may be selected.  Beyond the 4/8 data bits - GPIO must drive RS, R/W (unless you will only/always write) and E (strobe signal).  So that's a 6/7 or 10/11 GPIO pin requirement.

Now the 4 bit "GPIO saving" is attractive - but 4 bit interface code is more complex - and the initialization code is severe & demanding.  And - 4 bit operation may, "run amuck" due to noise burst - leaving the screen disordered - and difficult to recover.  Thus - 8 bit interface is my suggestion till you've built experience/confidence.

One last point - trips many - one pin (usually Vo) [operating voltage] must provide the contrast voltage - normally near ground for modern displays. (0V - 0.7V wrt ground)  Older displays - and wider temperature units (-20 to +70C Op.) often require Negative voltage upon Vo.  Usually - 1.2 to - 2.5V will work.  10K pots provide a comfortable means to adjust - if no negative source V is available old standby 7660 IC provides eased/low-cost +5V to -5V conversion.  The contrast pot should be adjusted so that the display's pixel field is just visible "after" the display has been initialized and the cursor "homed."  Misadjustment of contrast voltage can cause the display to be totally dark - or more normally totally light - with no pixels visible. Adjusting contrast before initialization usually renders the display "too dark" after initialization.

And - now a real last point.  Most modern MCUs run 3V3 and most displays still operate from VDD=5V.  We've yet to find a 5V text display which would "complain" when data bus and control pins are driven high by 3V3 MCU.  Now it is likely that should you "read" the display - the 5V display will output near 5V to your MCU's GPIO while the E pin is active.  You must insure that any GPIO connected to display data bus are 5V tolerant. (if you will read the display)  Some - but not all - 5V displays may run from VDD=3V3 although in this case most always the contrast voltage must be negative - perhaps almost reaching to -5V.  Never allow negative contrast V (if any) to rise or persist in absence of VDD to your display...

Hi cb1,

Yup I'm aware of all these complexities. Yesterday, I wrote driver for the same considering the 4bit interface and it became very complex as you mentioned. Will try an 8 bit interface today and check with the results.

Regards,

Gautam

Hi back,

Experience teaches you'll be far ahead - starting w/suggested 8 bit interface.  It's not just the interface - but the 10 or so key command codes which also must be mastered.  And starting w/4 bit interface adds a layer of complexity which many deem unwise.

There's one more key point - may aid you/others.  (especially appropriate here - an MCU & SW site)  You should resist the temptation to "save an instruction" by toggling RS, RW & E together!  RS and RW may toggle together - but E requires its own instruction.  (to meet both set-up/hold time of RS & RW)  So - for the most robust transactions w/most HD44780/clone based text Lcds:

a) Output appropriate levels to RS & RW (RW - if used, tie to gnd otherwise)

b) present 8 (or dreaded) 4 bit data to DB7-DB0 (or DB7-DB4 - lower pins will "pull weakly high" - may remain unconnected)  Always best to choose/marry 8 bits from a single port to attach to lcd's DBus.  And - insure that lowest MCU bit ties to D0 of the display.  (clients have missed this!)  Certain ARM MCUs may output 16 bits on a single transfer - and so long as DBus, RS and RW "only" are simultaneously written - this is acceptable.  (Note "E" restriction - above)

c) Output high to E (meet minimum spec width (past  ~250nS)  Today's MCUs may violate (too narrow) w/back to back - E up then E down

d) upon meeting/exceeding spec'ed E "high" time - drive E low

This sequence should cause the ASCII character as defined by the DBus to display.  Older displays require ~40uS before being "ready" for the next character.  Users may "solve" this requirement by inserting fixed ~50uS delays - prior to any character write.  All display transactions may be speeded by "reading" DB7 - which announces when the display becomes ready - eliminating the need for a fixed delay.  (but requiring GPIO tied to RW)

And there's another trap - Clear Display (0x01) and Home (0x02) both require far longer delays.  (2mS usually is safe)  Again either a fixed delay (now you have 2) or a looping read of DB7 (display's busy bit) often speeds execution/display burden.

Text Lcds require that RS=0 prior to any command.  (i.e. Clear, Home, Cursor Address, Initialize etc.)  RS=1 prior to any character write.

Keep in mind that 4x16 & 4x20 both must be initialized as 2 line displays.  (not 4)  (4x40 displays usually employ 2 independent lcd control ICs - and each controller drives 2 display lines.)

One final justification for 8 bit DBus (rather than 4) - users often graduate to small graphic displays (mono or color) and (to my best knowledge) none accept the 4 bit nibble interface - preventing eased/speedy migration to larger and more flexible displays...  (you must design/spin another pcb...)

And...here key timing/signal extracts from venerable HD44780 data sheet:  [a true copy (each)]

Gist of this is that (as previously detailed) RS, RW (and data - if MCU can output beyond 8 bits) may change via single MCU instruction.  E then may follow but must comply w/set-up - width - and hold times - as shown/listed. 

Beyond these signal timings - HD44780/clones have execution times - which vary - and depend upon the specific lcd command issued.  In general a 50uS delay between character writes - and a 2mS delay after a clear or home - will work.  (or - DB7/busy bit may be polled to discern "ready")

Hello cb1,

could please brief how did you made 8 bit interface code for this application (I am sorry, if your work data is not confidential).

sending 8 bit data to GPIOs quite difficult by bit instructions.

I am trying to make the interface coding for 2*16 LCD, could not make it working.

Thanks

Rafeeq MUHAMMED said:

sending 8 bit data to GPIOs quite difficult by bit instructions.

Difficult and tedious - my friend.  So - choose/dedicate an 8 bit Port (or beyond - as/if available) for your MCU -> LCD data bus.  Then - via API or your own creation - output a byte via this 8 bit bus.  (StellarisWare API has a function - which includes a bit-mask - thus enables: single, several bits or full byte output)  (note - other ARM MCUs may output 16 bits via a single instruction/function call)  You should be able to read/write a full byte - via a single function call.  (one would hope)

A 2nd Port may serve to supply: RS, RW and E strobe.  As mentioned/emphasized earlier - these should be "bit oriented" functions when involving "E."  (RS, RW may toggle together) 

For normal/customary 2x16 - initialization code of 0x38, 0x06, 0x0E and 0x01 should CLS (clear screen) and home the cursor.  These 4 bus codes sent w/ RS=RW (low) and with a proper "E" strobe for each.  (thus 4 E strobes in total - sent)  After this init. - if you have properly handled the Vo (display contrast) pin - the pixel field should be just visible - with the cursor at high contrast.  10K pot "de rigeur" for ease of contrast adjustment.  (wiring earler described)  Should pixel field not reveal - either the init was improper - or the contrast voltage is incorrect.  If you cannot view faint pixel field - and strong cursor - at this point - further data input unlikely to correct.  (double check your output sigs)

Once the init yields results above - you are ready to send data.  First, set RS=1, keep RW=0 and now present 0x41, 0x42, 0x43 (each accompanied by E strobe) upon the data bus.  "A B C" should appear - top row of the Lcd.  Very hard for such not to result - if you've complied with and obtained the earlier init results.

To vector the cursor "home" on row 2 - set RS=0, RW=0, and place 0xC0 upon the data bus - then E strobe.  Cursor should snap to position 1, row 2.  To return the cursor to home - row 1 (w/out clearing the screen) use 0x02 or 0x80 - both w/ RS=RW=0.  To move to column 10: 0x8A (row 1) or 0xCa (row 2) - same RS/RW settings.

Famed, "could/does not work" fails to provide necessary (any) detail to enable full diagnosis.  If you follow instructions herein - and comply w/timing charts supplied earlier - and display is good - your display should be, "On the Air." 

Good luck...

 Hi if you search on MSP430 forum I followed a struggled post and I adjusted to do 4 bit interface on simple 2x16. 4/8 bit interface is not the main concern but timing the worst during initiation where no busy bit is available.
 I got that example fully commented and workind due to the particularity it can connected to spare bit and this can help connect on a limited resource, you can get inspired by, today serial devices (TFT too) cost less than traditional and when a COG cost 1.5$ using parallel lose interest.

@Roberto:

RIP....KISS!  Oh well - if you say/believe so!

Having sold/delivered > 100K such displays - dispute your claim that 4 bit interface (despite its 4 GPIO "saving") is proper/appropriate or even "sane" for new user.

Indeed - the initialization into 4 bit mode is fraught w/peril!  And - when past init. - any glitch upon "E" - when in 4 bit mode - very likely causes the nibble transfers to become, "one off."  And then - any/all subsequent display reads or writes will fail - rendering the screen quickly unreadable - and unrecoverable.  (I know how to recover - but now is not time nor place)

This thread focused upon simple, character based displays - and all guidance I supplied was to that end/objective.  Despite your dismissal - these now 30 year old character displays continue to fulfill multiple market needs - impossible to meet w/the added memory requirements of 8-24 bit/pixel TFTs.  (memory hungry images and fonts - spectacularly over-flow any MCU - thus external storage (adding cost, size, interconnect) is required - which you conveniently neglect!)

While you may have, "lost interest" - that personalization was not this thread's topic!   

I believe your post does disservice to users who seek the simplicity & effectiveness of the "time-proven" character Lcds...

 Hi CB1, first I am still using parallel displays on both LCD and graphics, the one I got trouble on TIVA was parallel and I never try'd SPI interface it support too.

 On the other hand I am starting using small character display with SPI interface that cost less than parallel.

Here is the MSP version, It can simply adapted to C2xxx or ARM.

On the other hand SPI display start cost less than old HD parallel interface so I cannot see why you undertand what is on your side...