matelot:
would you mind just writing the bare bones of a sketch that would put a word on the lcd that I could then experiment with and alter as my understanding grows?
Unfortunately, as I said in post #7 that is simply not possible.
(There are 40,320 possible permutations of how the PCF8574 output port pins could be wired up to the LCD)
It is the equivalent of you wiring up a LCD directly to Arduino pins and now asking for someone to provide a sample bare bones sketch that uses the LiquidCrystal IDE library without telling how you wired up the pins. It simply is not possible. The LiquidCrystal library needs to know how the LCD pins were wired up to the Arduino pins; that is what the pin numbers in the constructor are telling it.
With fm's LiquidCrystal_I2C library class, it is the same.
In this case, the "pin" numbers in the LiquidCrystal_I2C constuctor are telling fm's library how the LCD pins are wired up to the PCF8574 output port pins.
Even though you didn't do any of wiring, and the wiring is hard-coded in PCB etch in the backpack, you still must tell the library how it is wired, because not all backpacks wire up the LCD pins to the same PCF8574 port pins and there no way to determine the wiring from s/w.
Until you get the constructor correct, which defines how the LCD is wired up the PCF8574 port pins, there is no way to put anything on display since the constructor tells the library how the LCD pins are wired up the PCF8574 port pins.
The library must know which PCF8574 output pin to wiggle to control each LCD pin function to be able to talk to the LCD.
In the ideal case the etch traces on the PCB between the PCF8574 and the LCD are closely examined or an ohm meter is used to determine how the PCF8574 pins are connected to the LCD pins to determine the pin numbers to fill into the constructor. Normally this only takes a few minutes.
Without knowing the proper pin information the odds of randomly determining it through trial and error are VERY low.
Consider this: there are 8 signals that could be wired up in any order. This gives 40,320 permutations of the wiring and then there are 2 possibilities for the backlight polarity giving a total of 80,640 possible different constructors.
Not something that could be tried at random since the odds of randomly picking the correct information is very low and when the constructor is filled in with the wrong pin mapping information nothing can be displayed on the LCD.
So as as an alternative to requiring people to have the skills to properly analyze their backpack, I wrote the guesser to try to help them by being smarter about how to "guess" at how the wires are connected. After examining many of the backpacks on the market, it turns out that there are only about 4 different pin wirings that all the backpacks are using.
It still requires guessing because there is no way for the s/w to know when the mapping is correct because the HD44780 interface to the LCD is being used in a write only mode.
i.e. the backpack will attempt to write to the display but it has now idea if the display is able to understand the signals - which it won't if the signal information is being put on the wrong signals from being told incorrect pin mapping information.
A human must be involved to look at the display to see if the guess was correct. When it isn't the human tells the guesser to advance to the next guess.
The potential issue with guessing pin mapping is when the guess is wrong, the signals are not talking correctly and depending on several factors, it is possibility that there could be situation where both the LCD and the PCF8574 are fighting each other to control the level a signal line. In this case, it is possible that it could cause damage to either the backpack or the LCD. In real world experience most backpacks don't wire up the r/w signal the PCF8574, but rather directly to ground. For those backpacks there is no issue. Even on the others, the signal levels don't seem to have any fatal issues at least not during short periods of time while testing.
The point of the guesser sketch is to give you the exact information to put into the LiquidCrystal_I2C constructor.
Run the guesser, look at the LCD and when the guesser guesses the constructor correctly, it will show you what you what you need to put in the constructor. If the guess is incorrect, tell the guesser to guess again.
It really is just that simple.
With respect to this sample code:
LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin);
void setup()
{
lcd.begin (8,2); // initialize the lcd
// Switch on the backlight
lcd.setBacklightPin(BACKLIGHT_PIN,NEGATIVE);
lcd.setBacklight(LED_ON);
}
That example is using the old version of the constructor and also using some deprecated API functions.
It would be better to use the full constructor which tells the library how the backlight is wired up.
example:
LiquidCrystal_I2C lcd(I2C_ADDR,En_pin,Rw_pin,Rs_pin,D4_pin,D5_pin,D6_pin,D7_pin, BACKLIGHT_PIN, NEGATIVE);
void setup()
{
lcd.begin (8,2); // initialize the lcd, which turns on the backlight
}
The reason to use the full constructor is that it makes changing between interfaces easier.
Say you wanted to change from an i2c backpack to directly connected wires, then if you use the full constructor, all you have to do is define a different lcd object and fill in the full constructor for the class. The rest of the sketch code will "just work" with no changes.
--- bill