Connecting and Programming 128x64 GLCD with TM4C123G

Hello Vikram,

Correction: The TM4C123 is not a "Connected" LaunchPad. TM4C129 is a connected LaunchPad

Do you have the reference schematics for interfacing the LCD with the TM4C123 LaunchPad? Did you check the DK-TM4C123 for reference connections?

Regards

Amit

Hi Amit,

I'm using JHD12864E GLCD. Connection information from the following link.

http://ablab.in/wp-content/uploads/2013/08/JHD12864E.pdf

1. Which ports in the launchpad will go with my LCD connections and 

2. Which files in grLib contains information regarding port initialization and control

3. Will I be able to use primitive functions for texts and drawings as it is for my Monochrome Display from the library?

Regards

Vikram

Hello Vikram,

The panel that you have is a parallel display panel, which is not supported with a native LCD Controller for TM4C123 devices. The reason is because TM4C123 does not have a LCD Controller, only TM4C129 has that. So to connect it to the TM4C123 LaunchPad, you would need to do a bit banged GPIO to connect 10 GPIOs to the 10 pins of the LCD Panel(RS, R/W, DB0-DB7)

The entire initialization now has to be translated to GPIO bit banged writes and read. In case of DK-TM4C123 the file cfal96x64x16.c contains the process to access the functions for grlib and needs to be changed for the panel you have.

Regards

Amit

Dear Amit,

Thanks for clarifying the doubt. As per your suggestion I believe it would be better to switch to  EK-TM4C1294XL. 

Please explain the procedure to configure it with my panel.

Thanks in advance.

Regards

Vikram

Hello Vikram

You can switch to the DK-TM4C123 or DK-TM4C129 which have display panel integrated on the EVM. The Graphics Library is developed and tested on the two boards. That would save you time for the SW development.

Regards

Amit

 Hi Amit,

You previously mentioned that TM4C123 does not have a LCD Controller, only TM4C129 has that. Considering the target price of the end product we can only have the mentioned LCD panel so the development has to be done around JHD12864E only.

DK-TM4C123G has 96x64 OLED and DK-TM4C129 also has color LCD hence not suitable for the proposed application.

Hence please provide assistance for configuring the mentioned monochrome GLCD JHD12864E with EK-TM4C1294XL. 

Thanks

Vikram

Vikram Dewangan said:

Hence please provide assistance for configuring the mentioned monochrome

I'm quite sure he's (already) provided much able assistance.  Should not your request seek (more) assistance?

Is not any such "configuration" the simple choice of one 8 bit GPIO Port to supply the Lcd's data - and a 2nd port to provide the control signals & strobe?  Such seems not a very demanding task.

Lcd manual will list the Lcd's timing, signal levels, and command/control data codes & control bit settings.  Your job then is to mate those Lcd specifications w/your Lcd software while being mindful of the signal timing.  Depending upon the particular display - you may have to supply a somewhat elevated positive or negative contrast voltage.  (important that you get that right - wrong polarity or excess may "doom" your display)  For ease of adjustment a potentiometer often is employed - controlling the voltage @ the display's contrast pin.

Hello Vikram,

To clarify, I mentioned that TM4C123 does not have a controller by only TM4C129 has a LCD controller and what it looks like is that you want to use EK-TM4C129 as a product and add LCD on top it for your end product.

You have to first identify the LCD pins as given in the data sheet and map it to the pins on the EK-TM4C129. Also identify the power pins and the appropriate voltage pins on the board.

The next item would be to modify the grlib drivers to meet the requirement of Initializing the panel and communicating the pixel to the panel.

Regards

Amit

Hi Amit,

Your previous answers were of much help. 

Apart from GPIO related APIs and instructions like 'GPIOPinTypeGPIOOutput', 'GPIOPinWrite' etc.what are the basic Port Control Registers as we have DDRx PORTx PINx etc. in AVR, and what are the instructions to control individual pins analogous to these for our platform?

Like the following code would do wonders for Atmel devices.

DDRB = ob11111111;

PORTB = 0b10000000;

What will be the simplest instructions to translate the above codes. :P

Thanks.

Vikram

Hello Vikram,

I am not familiar with Atmel convention on GPIO access, but in case of TM4C devices the GPIO pins are bit banded. So if you want to write a value of 1 or 0 to a specific pin then you can access the pin alone w/o affecting other pins.

The address can be computed as the pins to be changed left shifted by 2. As an example if GPIO Pins 2 and 5 needs to be changed then the address offset will be 00100100 << 2 or 0x24 << 2 or 0x90

Hence to the base address of the GPIO you can do the following operation

HWREG(GPIO_BASE_ADDRESS+0x090) = value.

Regards

Amit

@ Amit,

In the, "heat of battle" appears you've (bit) violated the Amit-cb1 "rule" - "Don't employ Direct Register until you're far, far along - or the far simpler, vastly more understandable TivaWare fails to include user's desired operation."

Can of worms opens wide if this descends to, "Direct Register" solution.  (and "Ending Well" alert has increased in intensity...)

You cannot say it directly (but outsider sure can) poster needs to make "Basic Investigatory Effort!"  (appears he's read little!)

Management of GPIO is extensively detailed with code examples, MCU Manual, Driver Lib Manual and hundreds of forum posts.

Hello cb1,

Indeed rule violated as it cam w/o the "ALERT: Not recommended unless very familiar with TM4C devices".

However, it seemed that giving the equivalent for Tiva at the point makes comfortability index rather better, especially when there is an uphill task for the poster to update the grlib using GPIO bit banging.

Regards

Amit

@Amit,

Indeed that "equivalency beckons" - yet "can of worms" soon follow - and overwhelms - I guarantee that.

I've designed/sold over 50K of similar 128x64 Lcd module.  No bit banding is needed for 8 bit data bus - and unlikely for RS, R/W & E strobe.  All can be achieved quite easily via standard Driver Lib - our group has done that for years.

Here two (proving) photos - one of poster's desired (size) display running under LM3S811 & the other one of our software & display (only) deliveries (on an LX4F) - developed for medical client  who (got to "enjoy" Agency approvals) - as we often are "component only providers."   Big seller - throws off cash even today...!  While we used (some) direct register - all of our "proof of concept" was done (just) w/Driver Lib - and you see results...  Bottom photo "cropped" per legal...(& larger display)

Hi cb1,

Your profile and your thousands of posts floating around forums portray your experience and your grip in the domain. 

My very first question in the forum was how can I interface the particular LCD with the launchpad.

So instead of juggling around all the unnecessary information I would really appreciate a direct point to point answer to the same.

With all due respect if you really wish to help (that's what this space is meant for) you may point out steps to configure GPIOs, initialization code for the LCD and changes which has to be made in grLib.

Thanks

Vikram

My friend - read again my posts - your thread - info is there for the taking.

Did I not (far earlier) advise:

"Is not any such "configuration" the simple choice of one 8 bit GPIO Port to supply the Lcd's data - and a 2nd port to provide the control signals & strobe?  Such seems not a very demanding task.

Lcd manual will list the Lcd's timing, signal levels, and command/control data codes & control bit settings.  Your job then is to mate those Lcd specifications w/your Lcd software while being mindful of the signal timing.  Depending upon the particular display - you may have to supply a somewhat elevated positive or negative contrast voltage."

Such info enabled me to co-found - take display tech firm public - w/in 4 years - starting from ZERO!  (yet you judge it "lacking.")

In protest of your "dismissal" believe I'll remove those LCD photos - or (again) raise pistol to my head.  (but I won't do it using "Direct Register" - will use, "PistolWare" instead...)

Gimme my (deserved) Verify...  (this Luis guy's getting too close...)

(and thanks for your Forum behavior guidance - will take that into full consideration....)

I didn't understand. Maybe it's Fourier eating away my brain, but i am a bit slow today.

@Luis,

Read again - (slower this time)...  And "I don't understand WHAT?"  I'm on a jet to client in moments - be quick...

Disregard my comment, i think i understood now.

Good for you - but if you truly read my "response to dismissal" post - you'll note that I was the first/only guy to "mind" poster that elevated Contrast Voltage (either + or -) is required for such displays.  (I've designed/sold ton of these - sorta know this stuff)

Comedy Central now calling for, "PistolWare" - great to be a "creative" among, "Just the facts, Maam."  (where's that gun?)

Hi cb1,

I'm still stuck at writing the initialization sequence and it seems I'm way too far from seeing a real thing in the panel. :(

Apparently I have done GPIO mapping for data and control lines and looking forward to write initialization codes but data sheet is highly misleading (or I'm unable to derive sense out of it.)

So if you have your driver codes already written and working (as you showed earlier), will you mind sharing here with us?

Note: In the Tivaware there is a library for Kentec-320x240 panel provided by TI. I took help from there for pin mapping etc. but initialization codes are completely different. It will be great to have your input for the same.

Thanks

Vikram

Hi back Vikram,

My friend - have you not (already) awarded the cherished, "Verify Answer" - and that to another?  (what motivation thus remains for a struggling, "Forum Provider of Content?")  And - since issues (already) answered - what more's required?

That 320x240 Lcd uses a completely different Controller IC (if any) than (most) 128x64 modules.  I assume you inherited or e-bayed your Lcd - is that correct?  Can you (carefully & in ESD safe manner) read & post here the ID markings of the largest IC on your display.  (likely it's a Hitachi or clone - but help starts there)

Graphic display screens are far more involved than character modules.- when we started our past display biz there were NO graphic Lcds to be had.  Thus we had a more relaxed learning curve.

My firm designs/sells custom programmed MCUs & FPGAs which substantially "automate" the "Design In" process of text, small graphic and many (advantaged) TFTs.  The support for the "serious" programming of graphic displays is time-consuming, costly and without adequate thanks/reward - thus we produce/provide the best "alternative."  (and thus avoid the endless series of questions - many of which can be anticipated & prevented - while making a modest profit and speeding/easing client efforts)

Even if we assist you to place pixels (precisely) upon upper left (home) and bottom right (end) of your display - a huge amount of time/effort (i.e. software design) remains. 

Might you consider a text display?   Perhaps a 4x20 can be acquired - and is so much simpler to get working - and will (naturally) prepare you to "battle with the "magnitudes harder" graphic display - but that downstream.

Do accept that I'm not being unkind/cruel (not my nature) simply a realist - and one w/some/slight experience - this specialized field...

HI cb_1,

Thanks for writing back. Its well understood you are not being cruel/unkind otherwise you wouldn't have punched hundreds of buttons to write me back. ;)

I have been working extensively with Atmel devices and have developed numerous applications on top of it with 16x2 Character Display as well as 128x64 Graphics. (Although I didn't write the drivers completely it was generously provided by the community geniuses like you so with subtle modifications the development have been smooth)

Now since TivaC platform is new (Almost a year old I believe) so support wise its a risk to opt for it but my application requires certain features so I did it, similarly my selection of display panel isn't random. After a considerable thinking (optimizing target prize of the end product and features) it has been selected and acquired from my supplier.

After repeated trial and error I'm getting the initialization sequence running into the KS0108 controller as we speak, but getting a blinking cursor is a long way ahead. 

Next task is to integrate the primitive tivaWare grLib functions. 

So without 'experts and their advice' our ecosystem would have been hell for designers. 

Again 'no offense' but Verify-Candy will come automatically if your efforts take my work at least a step ahead.

Whats the name behind cb_1, I wonder!

Thanks for being a good sport. 

Warm Regards

Vikram

Vikram Dewangan said:

generously provided by the community geniuses like you

Many of our firm's clients (and several interns) may not (fully) agree w/that characterization. (slave-driver somehow lingers...but jury still "out.")

New info you've provided is most helpful - I designed a, "Forum Poster's" checklist - submitted here - it was awarded "sticky status" - and after 30 days broke free from "sticky" - rotated "off page" to forum oblivion.  if you can "hunt that down" and fill in those blanks - I'll try to carve out (further) time/effort to guide/support.

Iirc you have no (real) spec for that Lcd.  Hitachi led the way - almost all such controllers are clones - some "not quite" meeting Hitachi standards.  If Lcd spec's available please link or attach.  (always most helpful)

I've said that we've long been in display biz - both photos I supplied were years ahead of LMI's graphic lib.  (purchased by current vendor)  So - I'm not "your guy" to tease out understanding - then mastery - of vendor's graphic lib.  Again - that's not to my interest - my reality. (we believe our methods/madness superior (i.e. we go from "analog signal in" directly to circular or linear bar-graph & selectable size numeric display - via single function call - thus vendor's library appears less capable, even "backward.")  (imho)

Perhaps more fruitful (i.e. some "middle ground") would be your link to 128x64 code you've elsewhere obtained - I should be able to "massage" that into this vendor's MCU suitable format.

Can say that if you've succeeded w/character module - and used 8 bit data bus (rather than 4 bit) we should quickly/easily be able to get you "iniitialized."  I've visited hundreds of Lcd clients - 90%+ of, "Display won't work!" complaints result from user "butchering or neglecting" the signal management of the Contrast (usually Vo) and/or Vee pins.  (sometimes Vee is negative (in the past) - now there's movement to positive - CAUTION - mistake here (usually) will KILL the Lcd)

So - as you surely know - Devil in the details!  (have I said that?)

Our group harvests forum response via (different) sign-on IDs - this enables our marketing dept. to determine how/where the "contactor" found us...  Due to time/effort limitations (I put in enough effort - don't you agree?) - anonymity preferred.

Get us some specs - find that "forum improvement" post - fill in those blanks.  (best guards my time/use in your behalf...)

(and - crack staff notes your (slight) inconsistency in awarding Verify to another - seems his effort/skill/time judged superior - how is that justified?  and where is he now?)  (such unfairness sounds our Alarm Bell - withhold of (clearly earned) Verify appears manipulative...not an ideal trait...)