LCD 1602 (and similar) library / HD44780 data sheet (apparent) conflict

I'm doing some experiments with an LCD 1602 and have come across this issue.

Arduino libraries (or at least some) allow the user to ignore the R/W pin of the LCD 1602 and simply connect this to ground (which forces the device into a write-only mode). That would appear fair enough because usually you want only to write to a display, not read it. However, the data sheet for the HD44780 chip set, as used by the LCD 1602, has this note:

Note: Be sure the HD44780U is not in the busy state (BF = 0) before sending an instruction from the
MPU to the HD44780U. If an instruction is sent without checking the busy flag, the time between
the first instruction and next instruction will take much longer than the instruction time itself.

However, in order to test the busy flag, the device has to be in read mode. I guess that then that the decision has been taken to accept this time penalty ?

HD44780 Data sheet:

Sample LCD library: GitHub - arduino-libraries/LiquidCrystal: Liquid Crystal Library for Arduino

thats the reason why also the libraries which respect the BF, do a fixed wait for the first commands also.

However, in order to test the busy flag, the device has to be in read mode. I guess that then that the decision has been taken to accept this time penalty ?

Exactly, The older libraries simply delay accordingly. And very inefficiently. :roll_eyes:

I believe Bill implements a proper deferred timeout so that each instruction checks as to whether the previous one has had sufficient time to complete while other code can have been performed in the meantime. Or does read the busy flag if the hardware permits. :grinning:

OK. Thanks for the comments. It does appear that some of the liquid crystal libraries are very sluggish with lots of blocking code. I stumbled across this when I was developing a sniffer for the LCD 1602 data bus, which I have now written up here, in case anyone is interested:

The issue with reading the busy flag, in the Arduino world is that due to the way the Arduino guys defined the digital i/o API and in particular the poor way they implemented the digital i/o code on the AVR (pinMode(), digitalWrite(), digitalRead), it is so slow that the amount of time it takes to turn outputs into inputs is already way longer than all but 2 instructions take to execute.
So reading the BF flag will actually almost always be slower than using the default instruction timing.
Now if using a Teensy device, where Paul optimized the digital i/o code to be MUCH faster, using the BF flag can make sense.

The hd44780 library does not use the busy flag. It uses instruction timing.
There are two timings, one for clear & home and one for everything else.
The library does not do a blind delay after sending an LCD instruction but rather checks to see if there has been, or actually will be enough time elapsed before the next command has completed getting sent to the display.
I say "will be" because on devices like I2c the library takes into consideration how long it takes the bits to flow over the i2c bus as well. This picks up a small bit of time since an instruction can be just finishing up while the next bytes related to controlling the PCF8574 for the next LCD instruction are being transmitting over the i2c bus.

The hd44780_I2Cexp i/o class also handles the i2c packets to control the PCF8574 differently than other libraries so not only do you reduce blind delays from the better instruction timing processing, but the number of i2c packets is cut down, by usually half or more so you pick up quite a bit of performance from that as well.

--- bill