PeterPan321:
I do have a 4 button keypad on my current project though, and it requires NO I2C ;-). So maybe it would be wise for me to make this, and other I2C projects hold off on doing anything until I press the "any" key.
A 100ms delay should be enough time for everything to stabilize.
If you are worried about it, just insert a delay at the top of setup()
Also, considering the small code space available in these Arduinos, isn't it better to let address discovery scan be a separate app, and then just import the LCD's discovered I2C address into your code? Besides the wasted code space, it has to get tedious and convoluted to both "discover" I2C addresses, while simultaneously rejecting non-LCD addresses (RTCs, digital POTs, etc).
The amount of space depends on the Arduino. Parts like the esp8266 have many megabytes of code space.
While it does add code to auto detect the address and other things there is an advantage.
By doing the auto configure runtime, it means you can replace the LCD device with another one and it will still "just work" without having to edit/recompile/upload the sketch should the i2c address, pin mappings, or backlight control be different on the new LCD device. It offers "plug and play".
The address range for the PCF8574 is fixed and is different from other devices.
Currently, the library does support manual configuration but do to the way virtual functions work, the auto configure code ends up getting yanked in even if it isn't used. That is something that I'm working on. I think there is a way around it with some clever use of templating. i.e. runtime virtual functions really aren't needed so I think I can use templates to compile time morph things rather than use virtual functions.
Ah... refactoring! I sorely miss being able to do all my development in Eclipse, if only for that wonderful capability.
In my case refactoring isn't something that could be done automatically with a tool, it is a re-write of certain portions of code to do things in a different way.
But I'd definitely recommend you DO make such an I2C backpack only version.
The only real difference (after some refactoring) with a backpack only version is that the library will be a bit easier to comprehend as it will be for a single h/w vs a library package with separate i/o classes for each h/w interface to the LCD.
It also makes things like finding the examples a bit easier since there is only 1 h/w interface.
I know a lot of forums try to steer people toward direct interface with the HD44780, the Arduino has a limited number of I/O lines and CPU time, has no tread or task management, and for my money LCD is THE way to go. Exception, of course, if you're talking to an LCD with graphic capability where you really need absolute max speed. But for character display, I2C is plenty fast enough.
The hd44780 library using i2c is actually faster at updating the display than the bundled LiquidCrystal library that uses direct pin control. This is do to the awful digital pin i/o code implementation in the bundled AVR core (Teensy code is 40x faster) along with some of the pin reinitialization bein done in the LiquidCystal library.
And the big win for hd44780 is the better way that hd44780 handles the command and data write timing to the LCD which allows the AVR to run in parallel with the LCD executing a command.
My final argument, of course, is that any substitution of WIRE functionality with a different I2C library will obviously be much easier, if everything is limited to a simple file.
Not necessarily. There can be a big difference in semantics. If the semantics are so different, it may not even be possible to provide a wrapper. Consider an i2c library interface that uses or requires callbacks or does buffered background i/o vs synchronous blocking i/o the way the current Wire API works. This is a very big change to the process flow that might be very difficult or impossible to fit into some existing libraries that use Wire.
My library might not ever boil down to be a single file. But when the code moves to a templated class, there shouldn't be any need to substitute anything or make any modifications for using different i2c interfaces or to use any i2c object with any name. i.e. Wire, Wire1, myWire, etc.... That is as long as the i2c library code provides a WIRE library compatible API - which most have done.
IMO any author that doesn't provide a WIRE compatible API is very foolish.
--- bill