Go Down

Topic: New LiquidCrystal library - LCD library (Read 26 times) previous topic - next topic


As for the Wire.h, every single sketch that uses the Wire library has to have the include in the sketch. It is a real pain. How did you sort this out in the GLCD? Relative includes?

Wire.h isn't a problem for GLCD is currently it currently doesn't use or support the 2wire stuff.  :D

With this new LCD  library the issue is that the sketch is not using the Wire library.
The LCD library is the the one actually using the Wire library.
And so the complexity is that when using older LiquidCrystal sketches, the 2wire stuff is not used at all
(no include for Wire.h) even though it is required for the new LCD library modules to compile.

This has to be resolved if you want the library to be a drop in replacement with no edits on older source.
To get it work, I changed the includes in I2CIO files to use "../Wire/Wire.h" instead of <Wire.h>
It works, but it means that the library must live in the arduino libraries directory vs under the uses sketch area.
This probably isn't that big of an issue since in order to use it they have to remove the originally supplied
LiquidCrystal library because this new library cannot coexist with the current LiquidCrystal library.

Have you thought any more about just not providing 100% backward compatibility by default
by say having a hd44780 library and then provide a LiquidCrystal class or thin library
that can be turned on for those that want full compatibility at the expense of removing their current LiquidCrystal library?

Or perhaps maybe never offering 100% backward compatibility and always require them to
edit their code to use the new library?
The edits are quite minimal and are limited to header file names and constructors names.
That way you don't require them to make any changes to their existing Arduino install and they can install
this new library in their sketchbook area.
They can use the new library if they use the new library headers and constructors
and get the stock LiquidCrystal library if they use the LiquidCrystal headers and LiquidCrystal constructors.
It would keep a very clean separation and allow them to install or remove the library in their own
sketchbook area.

--- bill


Oct 31, 2011, 12:10 am Last Edit: Oct 31, 2011, 09:43 am by fm Reason: 1
Ummmm! I need to reconsider after seeing how the entire compilation chain works (people wonder why I like to develop my stuff with eclipse).

For the linker problem, I got round it by not declaring the "begin" and "send" as pure virtual methods. For some reason, which I still need to figure out, the thing doesn't like pure virtual methods on the base class. If I change it to an empty method it is cool.

The nice thing I like about the library is that the I2C implementation on the example files are almost 700 bytes less that the 4bit library (not bad).


I've uploaded version 1.1.1 up to the repository, all tested in 0022 and 1.0-RC2.

Tomorrow, a bit more thinking and considerations regarding the library as a drop-in or not...



Rel. V 1.1.2 of the LCD library has been released with performance enhancements.

Release highlights

  • Version V 1.1.2 is 3.25 times faster than the original LiquidCrystal library

  • Minor comments added to source code

  • Documentation only available in .html format

Project wiki - https://bitbucket.org/fmalpartida/new-liquidcrystal/wiki/Home
Project donwload - https://bitbucket.org/fmalpartida/new-liquidcrystal/downloads


Version V 1.1.2 is 3.25 times faster than the original LiquidCrystal library

Which APIs?

Does this measurement take into account the slow down due to calling via the use of virtual methods?

Sounds very interesting. I will try to download next week.


Go Up