Busy Flag in Liquid Crystal library not used

[GoogleCodeExporter]

What change would like to see?
I noticed that the Liquid Crystal library is performing amazing delays of 
thousands microseconds instead of reading the busy flag. Why don't we use the 
busy flag, which was especially buit for this usage?

Why?
A lot of time is lost because of active waits.

Would this cause any incompatibilities with previous versions?  If so, how
can these be mitigated?
Not any incompatibility with previous versions.

Original issue reported on code.google.com by mmoottu...@gmail.com on 13 Dec 2011 at 4:12

[GoogleCodeExporter]

I think you need to check out a few of the LCD shields ,
before stating "Not any incompatibility with previous versions"

1. If you check some shields the  RS,E & D4-D7 lines come out, BUT the R/W pin 
has been hardwired to the GND connection, which is not really a smart decision. 
The library would need to be structured in such a way that IF the user did not 
pass the  R/W parameter in LiquidCrystal()
Then the code would assume no  Busy flag was available.

2. Not all LCD offer the functionality of a "busy" bit even though they have a 
R/W

Original comment by practica...@gmail.com on 14 Dec 2011 at 9:10

[GoogleCodeExporter]

John Raines implemented the busy flag check and many other improvements in 
early 2010.  John's version was planned for Arduino 0019.  It was never 
included.  Arduino 1.0 still ships with the old (and slow) LiquidCrystal.  
John's work appears to have been abandoned.

I updated John's code for Arduino 1.0 and renamed it to LiquidCrystalFast.  The 
name change allows it to be installed in Arduino without conflicting with 
LiquidCrystal, and you can easily change your sketch between the 2 libraries by 
just adding "Fast".

You can get LiquidCrystalFast here:

http://www.pjrc.com/teensy/td_libs_LiquidCrystal.html

A simple benchmark sketch is included in the examples.  If you run it on a 
display with R/W connected, you'll see the speed is significantly faster.

Regarding: "... IF the user did not pass the R/W parameter ... the code would 
assume no Busy flag" is EXACTLY how it works.  The original LiquidCrystal 
library allows using or not using R/W, but if you do opt to use R/W, it simply 
drives the pin low forever.  LiquidCrystalFast keeps the same constructors, but 
instead of just driving R/W low, it actually puts it to good use.  If you have 
a display wired without R/W, or the display doesn't implement a busy flag (are 
there really any that don't), you can always just use the constructor which 
doesn't include R/W.

LiquidCrystalFast has indeed been tested on MANY displays.  It is very 
compatible.  In fact, John even found a few problematic displays that don't 
work well with the original library, but they do work nicely with his version.

Original comment by paul.sto...@gmail.com on 14 Dec 2011 at 2:47

[GoogleCodeExporter]

Off course, the busy flag has to be managed in relation to the use of the R/W 
pin. But since there are different constructors (including R/W or not) it is 
possible to know when this flag can be used.

I didn't know that some LCD would not offer the busy flag even with R/W. The 
library is told to be "compatible with the Hitachi HD44780 driver" so I assumed 
the flag was available.

I noticed the library written by John, and it gave me the idea to check on the 
official library (LiquidCrystal) how it was managed. It is a shame it is not 
implemented into the new version.

Thank you for providing the link to this improved library.

Original comment by mmoottu...@gmail.com on 14 Dec 2011 at 6:32

[GoogleCodeExporter]

Hi,
" If you have a display wired without R/W, or the display doesn't implement a 
busy flag (are there really any that don't)"

i'm new to arduino (currently writing a library for production QA of them, 
which is why I found the '!!!' issue).
 I  initially thought the LCD library was a little more general, Since it is for a specific chipset (HD44780), this obviously does not apply.
But I am going to make sure we do an updated KB shield with the R/W connected 
to a pin.

Original comment by practica...@gmail.com on 15 Dec 2011 at 11:39

[GoogleCodeExporter]

Hi,

I would just like to add an information:
LiquidCrystalFast seems not to be compatible now whith Arduino 1.0. I 
downloaded this version, and it refuses to compile even an example of 
LiquidCrystalFast.

Let me know if I am wrong.

Original comment by mmoottu...@gmail.com on 20 Dec 2011 at 1:13

[GoogleCodeExporter]

Which example did you test?  Which board and operating system are you using?

I just tried compiling all 13 examples for Arduino Uno running Arduino 1.0 on 
Linux (Ubuntu 10.10, 32 bit).  I found 10 of 13 compile without errors.  3 of 
13 (CustomCharacter, TestAll, TestAllMega) fail to compile.  I will fix those 3.

Could you please provide more information?  I need specific details, so I can 
reproduce the problem.  It also helps greatly if, rather than simply indicating 
you saw an unspecified error, you would please attach a text file with an EXACT 
copy of the error(s).

Original comment by paul.sto...@gmail.com on 20 Dec 2011 at 5:17

[GoogleCodeExporter]

I tested several examples: HelloWorld, Display, Scroll and I get the same error 
compiling:

\libraries\LiquidCrystalFast/LiquidCrystalFast.h:101: error: conflicting return 
type specified for 'virtual void LiquidCrystalFast::write(uint8_t)'
\hardware\arduino\cores\arduino/Print.h:48: error:   overriding 'virtual size_t 
Print::write(uint8_t)'

on Arduino 1.0, windows 7

Would you need some other information?

Original comment by mmoottu...@gmail.com on 20 Dec 2011 at 6:12

[GoogleCodeExporter]

Opps, the website had an old version!  Sorry.

I've updated LiquidCrystalFast to version 1.1.  All 13 examples should compile 
and work on Arduino 1.0.  Please let me know.

Original comment by paul.sto...@gmail.com on 20 Dec 2011 at 6:25

[GoogleCodeExporter]

Well done!

I downloaded the version you've just updated. It compiles as expected.
Thank you for having promptly fixed the problem.

Original comment by mmoottu...@gmail.com on 20 Dec 2011 at 6:30