I have several questions on the backlight stuff.
It appears that your board uses I2C for the data and control lines but uses a dedicated pin for the backlight control.
Other boards use a pin off the i2c i/o expander to control the backlight.
I see some i2c backlight control code but it looks like it doesn't do anything yet.
It also looked like the i2c backlight masks in LiquidCrystal_I2C.h were assuming an active low signal
from the expander to the backlight would turn it on.
Is this is mid progress?
Is there a solder pad on your board to enable backlight control from the i2c output register instead
of having to use a dedicated pin? (yes no pwm but it saves an AVR pin since on/off controlcould be done through i2c)
The backlight control is challenging, since it looks like it can potentially be
done in multiple ways and can potentially be an active high or active low signal.
Michael and I punted on backlight control so far in the glcd library so I'm very interested
in seeing how this works out.
I think it would be really nice if the backlight control were a function in the base lcd class
so that it could work across all the interfaces rather than just the devices that add it in
as a user expansion.
The tricky part is how to configure it.
What makes it particularly difficult is all the combinations particularly on i2c.
Since the constructors must be able to distinguish between using an AVR pin and a bit
in the i/o expander.
For full flexibility the code also has to know whether the backlight control is active high or active low.
And then there is PWM control.
I'm not sure about the initialization but what about using an interface that is slightly different from
the display() nodisplay() interface for backlight control?
What about using backlight(pwmvalue) as well as backlight() and nobacklight()
The interface can be used for pwm as well as non pwm.
That way people can turn it on and off and try to use pwm on all devices and those
devices that don't support pwm simply turn it on if the pwm value is non zero.
Just an idea....
The magic is figuring out how to configure the pin.
It seems pretty easy to handle the active low stuff.
One possibility is If the constructor is configured to take integers (int or int8_t vs uint8_t) then
you could use a negative value to represent negative logic (active low) signal
at least on the backlight pin.
I would think that when using 4 bit mode that the backlight pin (if specified) is always an Arduino pin.
The tricky part is how to select between an Arduino Pin and a i/o expander bit when i2c is used.
When using i2c I would think that the default would be that the backlight pin is an i2c expander bit
rather than a Arduino pin.
Maybe it could be handled with a macro so that the user simply specifies his intension in the constructor
and the macro ORs in some magic value to help determine which is which.
Examples:
LiquidCrystal_I2C lcd(lcd_Addr, En, Rw, Rs, d0, Â d1, d2, d3, Â iobit);
LiquidCrystal_I2C lcd(lcd_Addr, En, Rw, Rs, d0, Â d1, d2, d3, Â BLARDUINO(arduino_blpin));
LiquidCrystal_I2C lcd(lcd_Addr, En, Rw, Rs, d0, Â d1, d2, d3, Â -iobit); // negative logic
LiquidCrystal_I2C lcd(lcd_Addr, En, Rw, Rs, d0, Â d1, d2, d3, Â -BLARDUINO(arduino_blpin)); // negative logic
LiquidCrystal lcd(12, 11, 5, 4, 3, 2, arduino_blpin);
LiquidCrystal lcd(12, 11, 5, 4, 3, 2, BLADRUINO(arduino_blpin)); // maybe either or both for consistency?
Where BLARDUINO() is something like (avoid using integer sign bit)
#define BLARDUINO(x) (x|_BV(14))
Maybe even specify the backlight pin type in all cases for consistency.
just a thought.
Another area that may need some attention is the RW line in i2c mode.
Some backpacks like the adafruit don't use the RW line.
--- bill