Go Down

Topic: [solved] 16x4 LCD: Characters in row 3&4 are moved to the right (Read 3 times) previous topic - next topic

olikraus

Jun 04, 2011, 08:41 am Last Edit: Jun 04, 2011, 10:06 pm by olikraus Reason: 1
Hi All

I have 16x4 Display (KS 0066), which should be (according to http://arduino.cc/forum/index.php/topic,18671.0.html) compatible to the LiquidCrystal library. I followed connect instructions from the HelloWorld Sketch, so the display is used in 4 bit mode.

It almost works perfect, except that lines 3 and 4 are moved to the right, by four characters.
This means, any text after
 lcd.setCursor(0, 3);
will appear at
 lcd.setCursor(4, 3);

Any ideas?

Thanks, Oliver


Kaouthia

It's probably assuming it's a 20 character width LCD (20 - 16 = 4).

I would tell it to setCursor(16,1) rather than setCursor(0,3).  That's how I do it with 20x4 LCDs, just setCursor(20,0) or (20,1) to get lines 3 & 4.
John

olikraus


Hi Kaouthia

Yes, lcd.setCursor(16, 0) correctly addresses line 3.
Looks more like a workaround, but it works.

Thanks, Oliver

Kaouthia

It does seem a little odd, but I do remember reading somewhere that there was a specific reason it was like this, although I can't remember what that reason was right now or where I found it, heh.
John

olikraus

Here is the code from the lib.

void LiquidCrystal::setCursor(uint8_t col, uint8_t row)
{
  int row_offsets[] = { 0x00, 0x40, 0x14, 0x54 };
  if ( row > _numlines ) {
    row = _numlines-1;    // we count rows starting w/0
  }
 
  command(LCD_SETDDRAMADDR | (col + row_offsets[row]));
}

It seems that the row_offsets are wrong for my display.
I guess, this is really controller specific.

Kaouthia

Aye.  I think most people are either using it with a 16x2 or a 20x4, so the issue doesn't pop up.
John

olikraus

Finally I finished my RGB selection menu...



Thanks for the support!


jrraines

you need, in setup(), a line that says lcd.begin(4,16);




olikraus

Hi jrraines

Thanks for your reply. However, I the code, which caused the problem, included the begin statement. My original code is here. It has the described effect in lines 3&4.

Code: [Select]

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(12, 11, 5, 4, 3, 2);

void setup() {
  // set up the LCD's number of columns and rows:
  lcd.begin(16, 4);
  // Print a message to the LCD.
  lcd.print("hello, world!");
}

void loop() {
  // set the cursor to column 0, line 1
  // (note: line 1 is the second row, since counting begins with 0):
  lcd.setCursor(0, 1);
  // print the number of seconds since reset:
  lcd.print(millis()/1000);
 
  lcd.setCursor(16+1, 0);
  // print the number of seconds since reset:
  lcd.print(millis()/1000);
 
  lcd.setCursor(16, 1);
  // print the number of seconds since reset:
  lcd.print(millis()/1000);
}

liudr


Aye.  I think most people are either using it with a 16x2 or a 20x4, so the issue doesn't pop up.


If my recollection is right, there are two ways to address the LCD onboard memory (DDRAM?) that stores characters in a 16X4 display, 20 bytes for one line, the same way as 20X4, or 16 bytes for one line. I don't think the library can tell which way so it simply looks at 2 or 4 rows and makes a decision that is compatible with most displays.

liudr


Finally I finished my RGB selection menu...



Thanks for the support!




Nice work! Maybe you can use some of my library or not to expand your menu.

floresta

Sorry to get in here so late but my broadband service has been out for a week.   This problem has come up several times before, here's one instance back in September of 2009: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?num=1253367247

The problem with lines 3 and 4 being offset on 16x4 displays is due to the fact that the LiquidCrystal library does not currently use all of the information provided by the lcd.begin function.  As mentioned in reply #4 the library assumes that the starting addresses for lines 3 and 4 are always 0x14 and 0x54 whereas for the 16x4 display they are actually 0x10 and 0x50.

If you want to read about the reason for the curious addressing scheme for these LCD displays then check out the link to LCD Addressing at http://web.alfredstate.edu/weimandn.


Don

floresta

Quote
If my recollection is right, there are two ways to address the LCD onboard memory (DDRAM?) that stores characters in a 16X4 display, 20 bytes for one line, the same way as 20X4, or 16 bytes for one line. I don't think the library can tell which way so it simply looks at 2 or 4 rows and makes a decision that is compatible with most displays.


There's only one way to address the DDRAM in the LCD controller so there is no decision to be made by the library.  The real problem is that the same controller is used for all display configurations and there is no way to inform the controller as to which configuration it is driving.  Take a look at the link in reply #11 for the full explanation.

The problem here is in the cursor positioning, not in the storage of data in the DDRAM.  The library could be modified to actually use the information in the lcd.begin argument to correctly position the cursor for any display configuration.  I believe that John has already done this in his LiquidCrystal440 library.


Don

olikraus

@Don
I read information at http://web.alfredstate.edu/weimandn/lcd/lcd_addressing/lcd_addressing_index.html. Altogether it seems that the build in (shiped) Liquid Crystal lib is somehow incomplete regarding the unusual 16x4 display. However, i now have a workaround... so for now it is ok for me.

@liudr
Quote
Nice work! Maybe you can use some of my library or not to expand your menu.

Thanks. However, the 16x4 port is only a small part of the project i am working on. Actually I am working on a graphical user interface (http://code.google.com/p/m2tklib/w/list). It also should be portable, so I spent some time on the LCD port of the user interface. I am also aware of your excellent LCD library. It contains features, which i probably will never put into a graphical user interface. Great work!

Here is a picture of the same menu, rendered on a DOGS102 graphics display (however, focus has moved to the ok button)


Oliver

liudr

That looks great. I am going to expand my library to ks0108 display but more or less to stay text based. We could exchange some tricks. I am sure if our libraries share some aspects, users of both libs will appreciate. I am going to use java-like names for new stuff. This should make it easier for those with some java background.

Go Up