True T-72 Spec Sheet

[Ilene Dycus]

Manytimes people ask questions about how to fix their LCDs that don't display or displays wrong/random stuff. The following information, when supplied with your thread, will get your problem solved the quickest way. Fixing these problems ends up being mostly a frustrating experience unless the following are provided upfront without any "BUT"s. I believe several other helpers here would agree with me.

Provide what display or display shield you are using, with a link to the product page or spec sheet. 99% chance no one else on this forum has your exact display but having a spec sheet will be the closest to having that display in hand.

Provide what code you used, copy from your arduino IDE and paste it properly with the code tag, press #. Again no one will have your exact code even if you think it's THE standard code. There is a lack of standard here so everyone needs to have what you have to help.

Provide clear high-resolution pictures of your connection between arduino and LCD, giving enough angles/shots to allow someone to physically trace every wire from point A to point B. Your "My circuit is correct and beautiful" argument stands better if you accompany your argument with a few clear pictures. If you drive a car, you wouldn't want an online mechanic to fix your car without even seeing the picture of your beautiful car, would you?

In case your display is not behaving the way you want it to be, say it displays xyz when you tell it to do abc, provide some pictures of the wrong info and tell us whether the display always does this wrong in the same way or random wrong way.

Be polite to critiques. I rarely see helpers does nothing but ridiculing the help seekers. But too often the help seekers were too arrogant/ignorant to accept any critique. If you want to be applauded, hire someone of buy a magic mirror that can lie to you.

G-3) hooking up the glcd contrast pot to +5v and gnd (like a hd44780 pot) vs +5v and Vee (besides the gnd vs VEE issue, bad pot wiring is very common and happens all the time even when there are instructions in multiple places and diagrams for how to properly wire up the contrast pot)

G-4) hooking up the pins incorrectly because of wrong documentation. (hd44780's for the most part all have the same pinout) Users often assume there is a single "ks0108" pinout - yet I've seen over 11 different pinout combinations.

G-7) miscounting/interpreting pin #s on the mega board. I see this quite a bit. People sometimes start at the top for pin 22 and forget the +5 pins along the top or get the left/right pins backwards or get the pins skewed or off by 1 because of a visual parallax error when picking the pins.

actually there is a println() function. It is just that in most cases it doesn't do what is probably expected.

However, this hd44780 LCD library actually does support handling wraps and newlines:

_libs_LiquidCrystal.html

So that can create some confusion.

The #1 problem I see is that people don't/won't read instructions or pay close attention

to the tiny details. I think this comes from people that are not used to things

having to be very exact vs "close enough".

I think many issues on glcds that I see are often unique to glcds and don't occur

on hd44780 type interfaces so not sure if it makes sense to really combine them all.

For example here are some of the more common errors on GLCDs that I see, some

exist on hd44780 display but some wont.

hooking up the glcd contrast pot to +5v and gnd (like a hd44780 pot) vs +5v and Vee

(besides the gnd vs VEE issue, bad pot wiring is very common and happens all the time

even when there are instructions in multiple places and diagrams for how to properly wire up the contrast pot)

hooking up the pins incorrectly because of wrong documentation. (hd44780's for the most part all have the same pinout)

Users often assume there is a single "ks0108" pinout - yet I've seen over 11 different pinout combinations.

miscounting/interpreting pin #s on the mega board. I see this quite a bit.

People sometimes start at the top for pin 22 and forget the +5 pins along the top or get the left/right pins backwards

or get the pins skewed or off by 1 because of a visual parallax error when picking the pins.

The new LiquidCrystal library now inherits from Print class so it has all the Print class functions including print, println with all the possible data types such as int, char etc. and the headache producer virtual write(uint9_t).

The fact is that there is no documented lcd.println() function provided by that IDE. This stems from the fact that the LCD controller itself does not inherently support the function and in fact treats the ASCII codes for and as displayable characters instead of control codes.

The LiquidCrystal library collects the information needed to implement such a function but currently doesn't use that information. It doesn't even use that information to correctly position the cursor on 16x4 displays.

The fact that the LiquidCrystal library inherits from Print class and thus permits the use of println() essentially makes things worse. Instead of barfing and spitting out an error message it just happily displays two unrelated characters on the screen and the uninitiated have no idea of the cause.

In my opinion the basic LiquidCrystal library should concentrate on implementing all of the capabilities of the LCD controller and no more. If people want a library that more closely emulates a CRT (or LCD) terminal that is fine, but I think it should be done in a different library. We should concentrate or efforts in this thread on getting the basic LCD functions working.

Good tread ! That should be a "sticky" tread. When I started to learn about LCD's. I came across this web site : Arduino Tutorial - connecting a parallel LCD. So I began to wired up an LCD display I bought at Active Surplus. I test the LCD using the examples codes from the IDE examples folder. And I lean about the LCD codes intructions at LiquidCrystal - Arduino Reference. And do a little at a time.

The fact is that there is no documented lcd.println() function provided by that IDE.

[/quote]

println() is in the Print class which comes with the IDE. It is inherited by the LiquidCrystal library.

The Print class is a bit of weird one. It is used by things like HardwareSerial, Softserial, LiquidCrystal,

yet it itself is not really documented.

In the documentation for the LiquidCrystal library the print class function println() was left

out since it wasn't supported by the supplied LiquidCrystal library.

But you will notice that it shows up in the HardwareSerial documentation.

Kind of. While the LiquidCrystal library does receive the and codes, it does not have any context as to what they mean.

The Print class got a println() call. It "knows" that there is a newline sequence.

But the and codes are handed down 1 byte at time to the LiquidCrystal Library.

They might be a newline sequence or they might be a character is desirable to print.

This is a more difficult thing to deal with and solve than would it would seem to be at first glance.

The problem is that you need to have both "raw" and "cooked" modes like real operating system drivers.

This allows the code to know if the characters are to be interpreted as potential commands or as literal simple characters to be

displayed. The Arduino environment never considered such needs so now things are stuck in the middle,

where the low level "driver" type libraries don't have modes but get handed these types of characters.

They can either interpret them as commands "cooked" mode (which is what the library on the Teensy site does),

or they can display them (which most do), or they could drop and .

The problem is there is no 1 single correct answer for what to do.

There are cases where any of those 3 options make sense.

i.e. sometimes you may really want to display character 0x0d on the display, an others

you may want a to wrap the location.

In my opinion the basic LiquidCrystal library should concentrate on implementing all of the capabilities of the LCD controller and no more. If people want a library that more closely emulates a CRT (or LCD) terminal that is fine, but I think it should be done in a different library.

That would be a bit limiting for most users.

Many users want to use the lcd display for displaying information, like strings and variables, etc....

The wimpy build model used in by the IDE makes it very difficult to have one library call another.

Even if the build model were done better, it would be more difficult for users to declare the needed

classes and objects to get one library to call another library or reference its objects.

As it is today and has been for several releases,

the LiquidCrystal Library (just like the HardwareSerial library) inherits the Print class.

This makes it much simpler to be able to do things like print a string or the value of a variable.

An unfortunate side effect is the newline issue on lcd displays when println() is called

because of the way the println() function is currently being handled (or not handled)

by the LiquidCrystal library.

Since people seem to be trying to use it, and expecting a behavior they

are not getting, I think it deserves a response by having an item in the s/w list.

S-2 is already there, but I'd change the language from:

"There is no such function" which is incorrect to

"It is not supported by most of the lcd libraries including the LiquidCrystal library that ships with the IDE".

Then if more detail is wanted, then mention, that:

With the LiquidCrystal library that ships with the IDE,

the sketch must control the display cursor position by using lcd.setCursor(x,y)

In order to scroll up all the text on the display, a buffer as large as

the size of the display is needed.

Once the buffer is scrolled, it can be used to re-write the full display.

3a8082e126