LiquidCrystal 4 bit mode initialization doesn't follow datasheet

Page 46 of the attached datasheet shows the initialization
method for 4 bit operation. The current (arduino-1.0)
code in LiquidCrystal.cpp looks like this:

  if (! (_displayfunction & LCD_8BITMODE)) {
    // this is according to the hitachi HD44780 datasheet
    // figure 24, pg 46

    // we start in 8bit mode, try to set 4 bit mode
    write4bits(0x03);
    delayMicroseconds(4500); // wait min 4.1ms

    // second try
    write4bits(0x03);
    delayMicroseconds(4500); // wait min 4.1ms

    // third go!
    write4bits(0x03);
    delayMicroseconds(150);

    // finally, set to 4-bit interface
    write4bits(0x02);
  } else {

It looks to me like there is an extra, unnecessary wait. I think the code should look
like this:

  if (! (_displayfunction & LCD_8BITMODE)) {
    // this is according to the hitachi HD44780 datasheet
    // figure 24, pg 46

    write4bits(0x03);
    delayMicroseconds(4500); // wait min 4.1ms

    write4bits(0x03);
    delayMicroseconds(150); // wait min 4.1ms

    write4bits(0x03);

    // finally, set to 4-bit interface
    write4bits(0x02);
  } else {

Anyone know why this difference exists? The latter code works for me.

hd44780.pdf (279 KB)

There not using read write pin on the LCD so just to be on the safe side the delays are longer.

If you feel a shorter delay is better and it works use it. There are a lot of clones that need more delay.

It may work fine for you and my buggie LCD may not like it.

But there is delay after the final write 0x03 where the datasheet doesn't seem
to call for one at all. I guess it doesn't hurt anything. I was just wondering if
its intentional or inserted by accident. I find the page of the spec sheet
describing the initialization sequence a little confusing.

After the third "functionset" it is possible to check BF (Busy Flag). If you do this it is not necessary to use a time delay.
You have the choice to check BF or instead of this to use the recommended delay. I recommend to check BF, because the value for time delay
depends on the manufacturer of LCD and sometimes you have to play to find the correct value.

happy feet

But there is delay after the final write 0x03 where the datasheet doesn't seem
to call for one at all. I guess it doesn't hurt anything. I was just wondering if
its intentional or inserted by accident. I find the page of the spec sheet
describing the initialization sequence a little confusing.

Sorry I'm late to the party - I don't usually read this part of the forum.

The delay in question is missing from both the 4-bit and the 8-bit flowcharts in the data sheet. I believe it is an editorial omission as there is no technical basis for it not being there. The controller has to process the instruction and that takes time. On the other hand there is no need to wait between the two nibbles of a 4-bit transfer since the controller doesn't do any processing until the second nibble has been received.

The fact that the busy flag can be read at this point is not documented as far as I can tell, but many have reported that it works.

By the way - it's funny that you didn't pick up on the fact that in the step after the actual Function Set instruction the LiquidCrystal library turns the display ON when the datasheet unequivocally says to turn it OFF. There's no "0 0 0 0 1 D C B" indicated in the flowchart, it is "0 0 0 0 1 0 0 0".

For my take on the whole process follow the LCD Initialization link at http://web.alfredstate.edu/weimandn.

Don