For those who weren't following the original thread (http://arduino.cc/forum/index.php/topic,53893.0.html) here's what is going on.
When polishdude20 ran the standard Hello World program he got the everchanging display shown at the beginning of his video. Since that program sends new data to the display every second or so it makes troubleshooting the display difficult.
The following program is a good one to use when testing an LCD that displays scrambled data or displays good data in the wrong location. It sends 80 bytes of data to the LCD controller which will put a displayable character at every location of every LCD screen from an 8x2 up through a 20x4 or 40x2. It will work on some 16x1 displays (which are actually 8x2 internally) but you will have to change the lcd.begin argument for other 1-line displays. By comparing what is actually displayed by this program with what should be displayed you can frequently pinpoint the problem.
#include <LiquidCrystal.h>
// Don't forget --> LCD RW pin to ground
//LiquidCrystal lcd(RS,EN,D4,D5,D6,D7);
LiquidCrystal lcd(7,8,9,10,11,12);
void setup()
{
lcd.begin(16, 4);
for (int i=33; i<113; i++) // send 80 sequential ASCII characters to the LCD DDRAM
{
lcd.print(i,BYTE); // display each character as it is stored
// delay(100); // un-comment to observe addressing sequence
}
}
void loop()
{
}
When polishdude20 initially ran this program he got this incorrect display shown at about 4:35 into the video:
When he un-commented the delay he got this correct display shown at about 5:10 into the video:
In my opinion he has an LCD controller that is operating at the edge of (or beyond) it's specifications. It seems to work OK when there is a delay between characters, but not when they are sent rapidly.
Take a look at the Execution Time column of the Instruction set (Table 6 of the Hitachi datasheet). At the top you will see that the execution time is specified for a specific LCD controller clock speed and at the bottom you will see a note that shows how the time changes at different clock speeds.
Now take a look at the AC Characteristics (page 49 on my copy of the datasheet) and you will see that the minimum allowable clock speed is less than half the speed used for the Execution Time column of the Instruction set. This means that a correctly written program, one that will work for every 'in specification' LCD module, will use much longer time delays than those in the datasheet table.
I believe that the LiquidCrystal library uses delays that are close to those specified in the Instruction set table. This works for the vast majority of displays, but not all the time as you can see. It won't be hard to modify the library if you are so inclined.
I may be able to add more to this when the results of the 8-bit test program are in.
Don