Go Down

Topic: 20x4 lcd oddity (Read 4523 times) previous topic - next topic

dnear1

Either I got a bum display or something is wrong in my code..

I took my (working) liquidcrystal test program and tried it with a new 20x4 LCD I got. Everything looks good on the first two lines until I go past the 10th character.  Only the left 2 columns of the 11th character light up what the character should be.. the rest of the display to the right of that and both bottom rows remain blank.  When the display is first powered up, both the 1st and 3rd rows are illuminated solid all the way across.. the same way my other 2 line lcds act..

floresta

dnear1:

Why don't you post your code so we can take a look at it?

floresta

dnear1

#2
Apr 21, 2009, 04:06 am Last Edit: Apr 21, 2009, 04:08 am by dnear1 Reason: 1
Code: [Select]
#include <LiquidCrystal.h>

//example use of LCD4Bit library

//#include <LCD4Bit.h>
//create object to control an LCD.  
//number of lines in display=1
//LCD4Bit lcd = LCD4Bit(2);
LiquidCrystal lcd(8,10,3,4,5,6,7);//rs, rw, en, d4,5,6,7

//some messages to display on the LCD
char msgs[6][15] = {"apple", "banana", "pineapple", "mango", "watermelon", "pear"};
int NUM_MSGS = 6;

void setup() {
 //pinMode(9,OUTPUT);
 pinMode(13, OUTPUT);  //we'll use the debug LED to output a heartbeat
 //digitalWrite(9,LOW);
//delay(15);
//digitalWrite(9,HIGH);
 //lcd.init();
 //optionally, now set up our application-specific display settings, overriding whatever the lcd did in lcd.init()
 //lcd.command(0x0e);//cursor on, display on, blink on.  (nasty!)
}

void loop() {  
 digitalWrite(13, HIGH);  //light the debug LED

 //pick a random message from the array
 int pick = random(NUM_MSGS);
 char* msg = msgs[pick];
 
 lcd.clear();
//delay(1);
 lcd.print(msg);
 delay(1000);
 digitalWrite(13, LOW);
 
 //print some dots individually
 for (int i=0; i<5; i++){
   lcd.print('.');
   delay(100);
 }
 //print something on the display's second line.
 //uncomment this if your display HAS two lines!
 
 lcd.setCursor(0, 1);  //line=2, x=0.
 lcd.print("Score: 6/7");
 delay(1000);
 
 
 //scroll entire display 20 chars to left, delaying 50ms each inc
 for(int i=0;i<20;i++)
 {
   lcd.command(0x18);
   delay(50);
 }
 //lcd.leftScroll(20, 50);
}


I have the rw pin tied to ground, not pin10.  it always worked that way with my other lcd panels.
in my liquidcrystal, I set rw to 255 and it doesn't "waste" the pin..
I even tried your liquidcrystal.cpp file as well as the original with the same results.

as far as I can tell, this lcd uses the ks0066 chipset?  it is SC2004cswb and I got it in Akihabara at akisuki denki for 1700yen

pwillard

#3
Apr 21, 2009, 04:28 am Last Edit: Apr 21, 2009, 04:32 am by pwillard Reason: 1
You do know that these devices have odd character mapping behaviors normally, right?   You don't have a bad device.  A library needs to take into account the DDRAM mapping so it behaves right when characters are loaded or shifted.

Declare it as a 2 line display and treat it like it is a 2x40 display while thinking lines 3 & 4 are the second half of lines 1 & 2.  If you look closely at the data below you will notice that line 2 of ANY display starts at hex 40...   maybe you can see that the designers were trying to make it simpler, but also ended up making it strange.  It ends up leaving gaps you have to live with in some display designs.


Here is some reference data I keep handy... forgot where I got it from.

Display Mapping:
Below are the standard DDRAM to display mappings for common LCD sizes. (in hexadecimal)

2x16 display:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F ... 27
40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F ... 67

2x20 display:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13 ... 27
40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 ... 67

2x40 display:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 01 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27
40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67

4x20 display:
00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F 10 11 12 13
40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53
14 15 16 17 18 19 1A 1B 1C 1D 1E 1F 20 21 22 23 24 25 26 27
54 55 56 57 58 59 5A 5B 5C 5D 5E 5F 60 61 62 63 64 65 66 67

floresta

dnear1

It looks like your conversion of the "fruit" example program is correct, although a little messy.  

This really isn't a good program for troubleshooting as it producing a changing display and we really need a static display.  I suggest you write a program that sends 80 successive characters to the LCD starting with 47 (0x2F).  Do this all in setup() and leave loop() empty.  Report back on what shows up on the display.

Quote
Everything looks good on the first two lines until I go past the 10th character.  Only the left 2 columns of the 11th character light up what the character should be
This is the part that bothers me.  If you look at the back of your display you should see 5 ICs (or 5 epoxy blobs).  The big one is the main controller, it has all the memory and takes care of displaying 16 characters,  This would be hex addresses 00 - 07 and 40 - 47.  Which are the first eight characters on the first two lines of your display.  One of the smaller chips displays the characters at addresses 08 - 0F and 48 - 4F which are the next eight characters on the first two lines of the display.  It looks like this chip is the one that is not functioning properly and it could cause problems for the remaining chips as well since everything is multiplexed.  The problem could be as simple as a solder bridge on the pc board.



pwillard

I don't think his problem is related to the odd character mapping.  Since this is an 80 character display every character he sends to the display should show up somewhere.

floresta

pwillard

I understand... but the layout of where characters show up is not always a known fact to new LCD hackers.

floresta

dnear1:

I ran your program and it works correctly on my RBBB.

Here's the test program I recommend for you to run:
Code: [Select]
#include <LiquidCrystal.h>

//LiquidCrystal lcd(rs,rw,en,d4,5,6,7);
//  LiquidCrystal lcd(12,11,2,7,8,9,10);      // my setup (matches original 4-bit example)
   LiquidCrystal lcd(8,10,3,4,5,6,7)            // your setup

void setup()
 {
   for (int i=47; i<127; i++)
   {
   lcd.print(i,BYTE);
   }
 }
void loop()
 {
 } 


Your screen should display something like this, some of the symbols may be different depending on the CGROM on your device:

/0123456789:;<=>?@AB
WXYZ[\]^_'abcdefghij
CDEFGHIJKLMNOPQRSTUV
klmnopqrstuvwxyz{|}~


Which characters actually show up on your display may help us diagnose your problem.

What 'pwillard' was pointing out is that the device actually displays your output on line 1, then line 3, then line 2 and finally line 4.  If you sent a few more characters they would start to overwrite line 1.

floresta


dnear1

#7
Apr 22, 2009, 01:57 am Last Edit: Apr 22, 2009, 02:01 am by dnear1 Reason: 1
I totally understand about the line layout.  

My LCD has 3 blobs on the back marked D1, D2 and D3.

I had my arduino setup unplugged overnight.

Oddly, except for a missing semicolon in your code sample
Code: [Select]
   LiquidCrystal lcd(8,10,3,4,5,6,7);            // your setup

it works fine and displays as expected except the \ character displays as the Japanese Yen symbol (overlayed Y and = if you don't know..) and the tilde ~ symbol is instead a right arrow symbol.

My sample code was really just the lcd4bitexample that has been floating around with some changes to make it take a few more characters

When I went back to my original sample, that is also working now..  so if it stops working again...?

Will have to see if it keeps working when I try to use elsewhere..

dnear1

#8
Apr 22, 2009, 02:08 am Last Edit: Apr 22, 2009, 02:20 am by dnear1 Reason: 1
After running a few minutes, the problem returned.

I re-loaded your sample code and it showed same issue on that one.. I could see /012345678 and the first 2 columns of pixels for the 9 on the first row
on second row, could see WXYZ[Y}^_' and the first 2 columns of pixels for the a on the second row, everything after including the 3rd and 4th row were dark.

Then a minute later, it drew in the missing pixels one pixel at a time on each character to complete the display..  right to left, top to bottom.  problem gone again..

going to run a while and see..  definitely sounds like a board problem and not a code problem.

floresta

Quote
definitely sounds like a board problem and not a code problem
I agree!  Get out your heat lamp and your CO2 fire extinguisher and try heating and cooling the board.  You might also try flexing it - there could be a broken trace or bad via.

floresta

Go Up