Hi Don, that is excellent feedback!
The coming release will take those values as inputs for home and clear. The only thing is that the original library is using a 2000us if I recall correctly. Therefore, there is a chance that it will not drive some LCDs.
Their 2000us is really at least 2173us on a 16Mhz AVR because they:
[ Timing for send() and writexbits() to set up the data/control lines]
(assuming current slow Arduino digitalWrite() timing)
- 4us to set RS
- 4us *8 to set the 4 data lines to OUTPUT (they assume data lines can be shared with other things)
- 4us * 8 to set the 4 data lines
So that adds another 68 us.
[then there is the pulseEnable() timing]
- 4us to set enable to LOW (which it already was) using the digitalWrite() function
- 1us blind delay after the above set to LOW
- 100us inserted an unneeded blind 100us delay after lower the enable strobe.
Their comment said "commands need > 37us to settle" which makes no sense
but they do need at least 37us here to cover the normal command/data delay since they have
no other delays.
IMHO, this last delay in pulesEnable() should actually be moved to the bottom
of send() since it has nothing to do with the enable strobe and is really
a delay for the command/data writes to the display to complete.
The Arduino delay functions are not very accurate so they all are probably actually slightly longer.
So their "2000us" delay is definitely long enough assuming the current 16mhz Arduino core code environment
and their existing code with all their other delays, some of which were not needed otherwise.
The 2000us command delay may break when the CPU is faster like say in a Maple environment or if the digitalWrite()
is finally re-written in a way that is significantly faster and the lcd is one of the super slow devices.
An interesting test would be to hook up one of these very slow lcds to a Teensy board
and try it since Paul does not use the Arduino supplied digitalWrite() functions so
his are significantly faster.
The code could be updated to actually support polling the BUSY status if a rw pin is handed down.
But my suspicion is that it won't be any faster unless you actually use 8 bit mode
which is a hefty pin requirement.
Maybe the simplest is to have some kind ifdef in the LiquidCrystal header that can be
turned on by those more advanced users to change the timing to a "typical"/"standard" hd44780
timing rather than the default of a worst case lcd.
(I'm assuming that the code will ship with delays set for worst case timing)
On a related performance speed up note:
In 4 bit mode there are 2 pulseEnables() so that adds an additional
105us in their current code.
(I didn't count that in the 2173us) as it may not matter since the command
is probably starting once the first strobe of the 4 bits is sent.
The significance of this is that they are also adding another one of their
goofy "settling" delays between nibbles.
If I remember correctly, there is no need for any delay
after a strobe of the first nibble in 4 bit mode, so if the 37us command/data delay was removed from pulseEnable()
and moved to the bottom of send() as mentioned above, that delay would only happen
once per command/data write vs twice.
This would be a significant speed up.