FYI:
The article by Gammon certainly fits with using stronger pull-ups (i.e. lower resistor values) leading to sharper pulse form.
But even with only one internal pull-up, the rise time to ~75% of max, ~4V, was only about 2 us. Now, he was using 5V parts and ESPs pins additionally have lower current capabilities, but it seems odd that the delays should be in the tens of ms range.
What country are you in? If postage is more expensive than the LCD ($6), I wouldn't either.
I am happy to work out the issue, don't care how long it takes, as I am using another library that DOES work until this is figured out.
Well, it appears it is uneconomical to have anything shipped from America to other countries unless its value is several times the US$50 shipping.fee. 
1 Like
I can't speak for Mr Perry.
If there is a hardware problem with a particular item that I want to fix. I often mail the reader with a working screen. And the reader mails the "problem" screen to me.
So the reader receives a "good" screen and I receive the "interesting" screen.
We each pay our respective postage. The reader has a working item for the cost of her postage.
I risk the postage and TFT failure.
But the wider Arduino community benefits. Bill Perry solves the LCD problem. I hopefully solve the TFT problem.
However the photos in #2 show a common backpack with a regular 16x2.
The soldering looks respectable. The breadboard wiring looks unusual. The straightened header pins may be suspicious.
Quite honestly mailing does not seem appropriate.
You just have to test "straightening" damage with a DMM and connect 4 wires correctly.
Paste the full diagnostic output.
David.
p.s. I don't believe that U.S. postage is $50. From the UK "Large Letters" are £3.75 to Europe. £4.20 elsewhere. "Small Packets" are £7.15 for regular countries. £9.35 for USA.
There is no point in signing or insurance for this sort of item.
Well, any time I have investigated purchasing from eBay or the major suppliers such as Digikey in the US, that comes up. Means I just do not buy from the US.
1 Like
So which country do you live in ?
My profile should say "Wormshill, UK" but only "Wormshill" seems to show.
I don't see how I can edit my location. There is no field for city, country.
I presume that something got lost when the Forum software got changed.
I avoid Digikey but for different reasons. Anyway there are good Distributors in the UK.
David.
I'm in Dallas, TX USA
I just added that to my profile - It was lost in the conversion over to this new Arduino social media platform.
It took me a good 15 minutes to find where to do it.
It is under Preferences -> Profile in the Location input box.
--- bill
So did you try adding a delay after the Wire.begin() in hd44780_I2Cexp.h ?
Maybe even do delay(1000) which is what LiquidCrystal_I2C.cpp does
A delay there should not be necessary.
Something odd is going on.
At this point, I'm suspecting either a h/w issue in that backpack/PCF8574 chip or some sort of a timing issue in the Wire library code that is affecting that particular PCF8574 chip that is triggered by the different initialization sequence/timing and faster code in hd44780_I2exp.h
Also, it isn't just the hd44780 code that is having an issue.
You had reported that the i2c scanner sketch was reporting a different i2c address than what the chip is actually strapped for.
To me, that is quite concerning as well.
I need to go off and look at the i2C spec and see a worst case timing of what a slave could potentially hold off from the bus should it see some garbage signals on the bus created during the Wire library begin() code that might look like traffic to some other slave.
The AVR Wire library does have some issues, and is possible that this LCD backpack issue is homing in on another one of them.
--- bill
Thanks for the tip. I still did not find it.
I got there in the end by clicking on the D icon at top-right of page. (D for david_prentice User icon)
User icon->Person icon->Preferences->Profile->Location
Regarding the HD44780 "problem". The backpack and 16x2 look "normal" to me.
Which implies a flaky Chinese jumper or a cracked pcb trace in the backpack.
David.
Moi?
Just corrected my profile. Probably the best at present, but NZ is pretty good too. 
Not too many school massacres (but the drug gangs seem to be having a minor barney - the police claim they have it under control now 
), petrol is up everywhere anyway, and the new government more-or-less believes Climate Change is real.
Maybe because of all the flood damage, needing to completely relocate major regional centres built on alluvial pains.
Thanks for the country. I assume you mean NSW, Australia.
Surely NZ is a long way from you.
It makes life so much easier when you don't have to guess.
e.g. you write "petrol" but I did not think you were from the UK.
As a general rule, it is very helpful to include your country.
There is no need to include your City.
The country implies language, timezone, climate, culture, ...
David.
It looks normal to me too. However, this is some kind of issue going on.
It could be wonky pcf8574 chip or it could be that you cannot starting scanning the i2c bus for a certain period of time after Wire.begin() is called to let the bus settle to allow time for the slave to see a proper stop/idle bus and this particular PCF8574 is tripping up over it when the time is shorter whereas others are not.
I've only ever had 1 other problem that showed up on a specific pcf8574 chip.
That one ended up being an issue in the hd44780_I2Cexcp code and surprisingly it only was an issue on this one particular chip.
I needed the actual hardware to find it. Once I had the h/w it only took a few minutes with a logic analyzer to see it.
In this case, nothing the hd44780_I2Cexp code is doing is any different than what the diag sketch scan does or what the i2c scanner does.
Yet it is not seeing the chip.
The only difference is the timing between the Wire api calls.
There are two things I would like to try to see if there is a Wire timing issue.
- adding the delay(1000) I previous mentioned in the hd44780_I2Cexp.h header after the call to Wire.begin() around line 754.
- moving a delay in the i2c address search code.
i.e. in hd44780_I2Cexp.h in the function LocationDevice() around line 726
change this:
for(address = 0x20; address <= 0x27; address++ )
{
Wire.beginTransmission(address);
error = Wire.endTransmission();
// chipkit stuff screws up if you do beginTransmission() too fast
// after an endTransmission()
// below 20us will cause it to fail
// ESP8286 needs to make sure WDT doesn't fire so we use delay()
// The delay(1) is overkill and not needed for other chips, but it won't
// hurt and the loop is only 8 addresses.
delay(1);
if(error == 0) // if no error we found something
To this:
for(address = 0x20; address <= 0x27; address++ )
{
delay(10);
Wire.beginTransmission(address);
error = Wire.endTransmission();
// chipkit stuff screws up if you do beginTransmission() too fast
// after an endTransmission()
// below 20us will cause it to fail
// ESP8286 needs to make sure WDT doesn't fire so we use delay()
// The delay(1) is overkill and not needed for other chips, but it won't
// hurt and the loop is only 8 addresses.
if(error == 0) // if no error we found something
It would be nice to test each of those delay modifications separately & independently to see if either one of those makes the issue go away.
Also, can you run this sketch so we can see the fuse bytes?
--- bill
Yes, over here we do use petrol to fuel our cars. Mostly. "Gas" is being mined here but we are trying to resist the lobbyists trying to expand to the expense of agriculture and boldly suggest it is more "climate friendly" than the black rocks.
I have been to NZ twice and that's as far as I have been over the water.
I live in Australia, postage is expensive to the UK! I just checked - $15.30 to ship to the UK!
Why is that? It works perfectly on other libraries wired like that, and with straightened pins.
Is that the serial monitor output?
Me neither.
I am happy to work out the issue, don't care how long it takes
Please run the tests with the library mods which Bill suggests. Shipping the specific unit to Bill would be a last resort.
If necessary to send something to Bill, I would be happy to pay for both the unit and the shipping. He has done so much for the Arduino community that he deserves all the support he needs.
You were not on the forum when we were dealing with several questions a week about hd44780 pin configurations and using the F. Malpartida library. The hd44780.h library has made the situation very much better.
1 Like
I am working on that now.
Why would the LCD work with other libraries if there was a cracked trace?
Compiled for ATmega328P
No Serial Number
Fuse bits (L/H/E): FF DE FD
Lock bits: CF
Signature: 1E 95 F (ATmega328P)
Oscal: AE
Fuse Low = 11111111 (FF)
||||++++______Low Power Crystal 8 - 16MHz
||++__________Start Up Time=11
|+____________Clock Output Disabled
+_____________(no divide)
Fuse High = 11011110 (DE)
|||||||+______Reset to Bootstrap
|||||++_______256 words (512 bytes)
||||+_________EEPROM Erased on chip erase
|||+__________Watchdog programmable
||+___________ISP programming enabled
|+____________DebugWire off
+_____________RST enabled
Fuse Extended = 11111101 (FD)
|||||+++______Brownout at 2.7V
Lock Bits = 11001111 (CF)
||||||++______Read/Write to everywhere
||||++________R/W Application
||++__________No Write to Boot, no read from App
Bootloader at 0x7E00 is not readable
hd44780_I2Cexp behaves differently than LiquidCrystal_I2C during initialization.
It is possible that a marginal connection might alter the signal integrity that could affect operation.
While it seems unlikely it is a possibility.
I have seen an issue where a hair laying across soldered pins causes issues - very strange issues. In that case it messed up the E signal and the RS signal.
I have also seen multiple cases of the PCF8574 chip not being properly soldered to the board and it caused strange issues.
This issue is interesting - at least to me.
The main reason I find it so interesting is that it is only showing up on this particular device - and maybe one other a few years ago.
i.e. hundreds of people have used this for many years on many different Arduino platforms running at different speeds, 8 bit to 32 bit and on backpacks from many different vendors and have not experienced this issue.
Now there have been some changes to the Wire library recently (like the past two IDE releases) that definitely affects the i2c signal timing and perhaps that is related to this issue.
The reason I wanted to see the fuses was to see if the AVR was using the crystal vs the internal oscillator or perhaps running at different speed than the 16Mhz the ide was told.
Can you run the other 2 delay tests?
Those will see if the added delay used in LiquidCrystal_I2C during initialization is a factor for the issue on this particular backpack/chip.
Also, can you turn on verbose output and post that so I see which tools the IDE is using.
The reason that this can be important is that the IDE no longer ensures that the tools and libraries come from the installed IDE package (dumb "feature" IMO),
i.e. the IDE will use the latest tools it sees for a given architecture.
What this means is that if you install an add on board package that includes newer tools than what is in the IDE, the IDE will use those instead.
This is problematic since the IDE tools and libraries are no longer stable or assured to be what came with the IDE.
For example you could install another AVR board package that affects the build for the UNO.
--- bill