Problem with WH1604B and LiquidCrystal

LeafLabs Garden » Support » Maple Hardware Support

Problem with WH1604B and LiquidCrystal

(15 posts) (6 voices)

Started 4 years ago by Roma
Latest reply from suso-mc

Roma
Member

I was try to use LiquidCrystal and WH1604B (16x4) with Maple Rev 5
This is my code:

#include <LiquidCrystal.h>

LiquidCrystal lcd(5,6,2,3,9,11);

void setup()
{
lcd.begin(16,4);
lcd.clear();
lcd.leftToRight();
lcd.home();

lcd.setCursor(0,0); lcd.print("Line1");
lcd.setCursor(0,1); lcd.print("Line2");
lcd.setCursor(0,2); lcd.print("Line3");
lcd.setCursor(0,3); lcd.print("Line4");

}

void loop() {}

and result not good

http://meteo.pajero4x4.ru/wp-content/uploads/2011/09/08092011222.jpg

Why

Posted 4 years ago #

gbulmer
Moderator

Have you tried any other tests? It is helpful to try a few tests to gather more evidence.

For example, do you get the same result if you do:

lcd.setCursor(0,3); lcd.print("Line4");
lcd.setCursor(0,2); lcd.print("Line3");
lcd.setCursor(0,1); lcd.print("Line2");
lcd.setCursor(0,0); lcd.print("Line1");

lcd.setCursor(0,0);  lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("1");
lcd.setCursor(0,1); lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("2");
lcd.setCursor(0,2);lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e");  lcd.print("3");
lcd.setCursor(0,3); lcd.print("L"); lcd.print("i"); lcd.print("n"); lcd.print("e"); lcd.print("4");

Posted 4 years ago #

Roma
Member

result the same as above

Posted 4 years ago #

Roma
Member

I found the problem.

in LiquidCrystal.cpp

this is correct addresses for 4-lines LCD
int row_offsets[] = { 0x00, 0x40, 0x10, 0x50 };
accoding Datasheet

void LiquidCrystal::setCursor(uint8 col, uint8 row)
{
  // int row_offsets[] = { 0x00, 0x40, 0x14, 0x54 }; THIS IS NOT CORRECT
  int row_offsets[] = { 0x00, 0x40, 0x10, 0x50 };  

  if ( row > _numlines ) {
    row = _numlines-1;    // we count rows starting w/0
  }

  command(LCD_SETDDRAMADDR | (col + row_offsets[row]));
}

Posted 4 years ago #

gbulmer
Moderator

Roma - Cool!

Your reply will help future user too.

(PS - I took the liberty of adding backticks to pretty print your code, I hope that's okay)

Posted 4 years ago #
Xavier
Moderator

It works fine as it is for 20x4 LCDs.
So maybe row_offsets shoud be initialized in the lcd.begin(...) function...

Xavier

Posted 4 years ago #
gbulmer
Moderator

Xavier - I was pondering having an initialiseRowOffsets function, but maybe initialising at begin is better.

Are those LCD's less than 256 characters?
In that case, the row-offsets could be:
uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 };
which would make for less initialisation.

Posted 4 years ago #
robodude666
Member

All commands sent to the LCD will be 8-bit, so there's no reason to dedicate a 16-bit int; it's just a waste of 4 bytes of ram.

However... There's nothing wrong with the library.

There are dozens of these kinds of LCDs on the market. They all look identical, and their controllers are extremely similar but they all have slight variations to the address mapping based on the configuration of the LCD.

The LiquidCrystal library included with libmaple is configured for a 20x2 or 20x4 LCD, for example the GDM2004D (see page 8 of 9). The other common LCD used is the HD44780U. The controller used by the WH1604B in the OP's post is the KS0066. As you can see, the GRAM addresses for the last two rows are slightly different between the GDM2004D and the WG1604B's KS0066 controllers.

Each LCD configuration (16x2, 16x4, 20x2, 20x4) will have slightly different GRAM address mapping. Because of this, I think it would be wise to include ALL of the possible row_offsets array in the Library, and require a value to be passed to the LiquidCrystal library that states what LCD is being used so that the correct offsets are selected.

-robodude666

Posted 4 years ago #
gbulmer
Moderator

robodude666

All commands sent to the LCD will be 8-bit, so there's no reason to dedicate a 16-bit int; it's just a waste of 4 bytes of ram.

I am not talking about the commands in general, just the row-offset values.

I realise that this controller takes 8-bit commands, but I don't see a need to make that a feature of the public LCD API, and hence how the row offsets are defined, unless you are saying *ALL* LCD controllers which map onto the existing LCD library API have less than 256 character displays. It only takes one which needs an offset bigger than 255 to break that assumption, and hence break the API.

I think it would be wise to include ALL of the possible row_offsets array in the Library.

I am a big fan of KISS.
I am not a fan of pushing changes which are not tested.
Let's fix what is broken, and can be tested, and wait to see what else is needed?

We could modify begin to take a row-offset map along the lines suggested by Xavier.
We could change begin so that a row offset map is a required parameter, and have no default.
We could provide a row offset map for the two LCDs being used, and hence they can be tested before the changes are pushed.

A tiny amount of documentation to explain how to set up for a different LCD would be enough to support all other LCDs which would otherwise work with the existing library.

Of course, if you are volunteering to test "ALL of the possible row_offsets array" combinations on real hardware, then that is fabulous. Do you posses an example of them all?

Posted 4 years ago #
robodude666
Member
These LCDs feature an included table of 256 character table, and all commands sent to the LCD are 8-bit (the LCD can be used in 4-bit or 8-bit parallel mode). These are three of the most popular controllers on the market, other derivatives exist but they're only clones which feature the same instruction set. I haven't heard of any variants that feature an extended character table, though some may exist. It can be left as a 16-bit value, it doesn't really matter - it's only 4 out of 20 thousand bytes of ram.

I'm against the need for a person to pass in an array of GRAM addresses into a wirish class. The point of the wirish class is to simplify the use of peripherals and devices. At least half of the Arduino community doesn't know how to read a datasheet to extract the required offset values, and it would only create the circulation of 3 sets of boiler-plate code that will be copy+pasted. Instead we could have a simple begin statement such as:

lcd.begin(LC_HD44780U_CONTROLLLER, 20, 2);

which will configure the library to support a 20x2 LCD that uses the HD44780U's GRAM addresses. This features no "magic numbers" that get passed in. It's very clear that the LCD is using a HD44780U controller. Where as something like:
```
uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; // What does this mean???
lcd.begin(&row_offsets, 20, 2);
```
is extremely confusing to anyone who doesn't know that those are the beginning address of each row. A user may attempt to change them, and will wonder why the LCD stopped working as expected.

While I understand the need to decouple the library from specific controllers, it would only end up making the public APIs more confusing to use for beginners.

If we want to make everyone happy, the LiquidCrystal library can have a private member that holds the offset values. The begin method will accept either a controller's name or a special "NONE" value. If a known controller is passed in, the member will be populated with the corresponding values for that controller/row/col configuration. If a special "NONE" value is passed, the user has the right to update the offset array using a setter method. This will allow easy use for common LCDs, and if a less common controller is used, the library can still be used once the user gets the correct offset address from the datasheet.

-robodude666
Posted 4 years ago #
gbulmer
Moderator
robodude666 - I absolutely agree that there should be meanignful names for the default values provided by the library. What did I write to cause you to think that?

I wasn't suggest anything as opaque as:
```
uint8 row_offsets[] = { 0x00, 0x40, 0x10, 0x50 }; // What does this mean???
lcd.begin(&row_offsets, 20, 2);
```
IMHO, that is tasteless and unhelpful.

is extremely confusing to anyone who doesn't know that those are the beginning address of each row. A user may attempt to change them, and will wonder why the LCD stopped working as expected.

If they understand so little, why would they NOT use a definition provided by the library?

I was thinking along the lines of:
uint16 LCD_WH1604B_ROWS[] = { 0x00, 0x40, 0x10, 0x50 };
which could be syntactically identical to your proposal, or even
uint16 LCD_20x4_WH1604B_ROWS[] = { 0x00, 0x40, 0x10, 0x50 };
to make it more explicit.

I'd consider:
```
struct _LCD_DEVICE_ {
    uint8 width;   // number of columns
    uint8 height;   // number of rows
    uint16 row_offsets[0];  // row offset values
};
typedef struct _LCD_DEVICE_ LCD_DEVICE;
LCD_DEVICE LCD_20x4 = { 20, 4, { 0x00, 0x40, 0x10, 0x50 }};
```
So that it is all wrapped up behind one name.

At least half of the Arduino community doesn't know how to read a datasheet to extract the required offset values

So in your estimation, almost half of Arduino community could find the necessary information, and hence code up something to use an LCD all by themselves if the API gives them that facility?
Excellent.
I am all in favour of making it easy for people to reuse code beyond its original (tested) intent by providing open solutions.

it would only create the circulation of 3 sets of boiler-plate code that will be copy+pasted.

No.
That would only be true if we didn't provide definitions for the default cases, which is NOT what I propose. I think we should provide definitions for the hardware we can test.

The code used for the supported cases would be syntactically identical.

Of course, the user would have to write code for a case not supported, but they have the option to do that if they need to.

other derivatives exist but they're only clones which feature the same instruction set

So, how does someone figure out which clone their LCD uses?
How do they define the properties so that the library works, and so that the parameter to begin is correct?

On a slightly different tack, if they are all the same controller anyway, and it is only the size and row offsets which vary, why should we make the name of the controller matter at all?
Posted 4 years ago #
crenn
Moderator

The values currently passed to the library through begin are enough to be used for the offsets.

Either chip uses Line 1- offset 0x00 or 0 in base 10, Line 2- offset 0x40 or 64 in base then. When you change have the 16 character wide variation, you get Line 3- offset 0x10 or 16 in base 10, Line 4- offset 0x50 or 80 in base 10. If you have the 20 character wide variation, you get Line 3- offset 0x14 or 20 in base 10, Line 4- offset 0x54 or 84 in base 10. Currently it's a minor bug in the library which doesn't involve a major redesign of it, it's an easy fix.

I'd suggest having the offset data moved as a private data member of the class, and at when begin is called, it sets up the offset:
offset[0]=0x00;
offset[1]=0x40;
offset[2]=offset[0]+cols;
offset[3]=offset[1]+cols;

That should fix the bug which minimal changes.

Posted 4 years ago #
gbulmer
Moderator

crenn - Are you saying all (practical) LCD controllers only need 3 numbers: line 0 offset, line 1 offset and cols?

Are there no 8 line LCD controllers in the same family of devices?

Posted 4 years ago #
crenn
Moderator

I haven't seen any, but there could be. There could be a lot of variations that we don't know of, however, at this present stage, we haven't had a request for anything more than 4 lines. Does the Arduino Liquid Crystal Library cater for larger screens?

Posted 4 years ago #
suso-mc
Member

Is there a LiquidCrystal Library version supporting serial port communication (UART)?

Posted 3 years ago #

RSS feed for this topic

Reply

You must log in to post.