Thanks bperrybap, it makes sense, since I made an exact copy breadboard setup, with the same result, making a poor connection less likely to be the problem. I will look into the library.
@jremington I hope this is good enough. If not please let me know.
And ........ I also experimented with a different setup for the buttons. The code one can find on this site, and with a resistor. It gave the same result.
It would be helpful to see an actual photo of your setup,
which others have also asked for.
--- bill
That issue was fixed quite a while ago. The library now has a timeout feature that you can set as needed
@blh64
It wasn't THAT long ago.
And I wouldn't say that this issue has been fixed.
The AVR Wire library added in what I'd call a kludge that allows certain spin loops in the library to optionally be configured to timeout.
And as I also stated, having the timeouts isn't the default mode of operation,
the API calls to enable these timeouts are non portable across other implementations, and there is no way for code that uses the Wire library to tell at compile time if the Wire library underneath it has the capability or not.
i.e. IMO, they really F'd up when they added these new API calls in the AVR wire library by not providing a compile time macro to be able to detect their existence.
(I proposed macros for this in the github issue and/or pull request for this code)
Not having these existence macros makes the code attempting to use this capability non portable.
It's also is a bit difficult to use there are no specific timeouts specified in the i2c spec for some of the timeouts. So what timeout values do you use? How long is enough?
While it did provide timeouts for the most common issues, I believe that there are a few remaining ones still there. (It's been a while since I went through the code)
In the bigger picture, using the AVR Wire library timeouts, particularly on a device like this one, (A PCF8574 being used to control a hd44780 in 4 bit mode) is not very easy.
Sure you can detect that something went wrong, but you can't ever really fully recover from it.
i.e. a library like LiquidCrystal_I2C or the hd44780_I2Cexp i/o class would have a very difficult time reliably recovering from a Wire library timeout error during a write to the PCF8574.
The only way to guarantee it would work would be for the library to keep track of everything the LCD is done,
i.e. exact modes and states, including cursor positions, all custom characters, and all data written to the display, etc...
This would allow the library to restore the LCD to the exact state it was in prior to the timeout error.
While it could be done, it would make the library much larger, much more complex and a bit slower as it would have to fully emulate the hd44780 chipset and keep all that information inside the library.
I had a few discussions about this in the github issues and on this forum.
Most people assumed that a simple retry could be done and that would get things up and working again, but on actual devices, particularly like this LCD device, that is often not the case.
So, IMO, while ensuring that library code never locks up,
the overall value of these Wire library timeouts is a bit limited and it came at the cost of always slowing down the code which slowed down the i2c data transfer rates regardless of whether timeouts were enabled.
There were a couple of long discussions on this, including one that got a little heated.
What was most disappointing to me was that there were some alternative proposals to add these timeouts that were more efficient code with less impact on performance.
One alternative was simpler, with less impact on performance but was rejected because it did not offer high enough perceived timeout resolution: either us or ns resolution.
Given these are error conditions having faster or more granular timeouts should not be necessary.
i.e. best practices is to optimize the normal runtime path, errors & exceptions can suffer a bit since they don't normally occur.
Even ignoring that, and using the API they came up with,
the actual coding implementation could be different / better to make it impact the data throughput less.
--- bill
Since I've tried various setups, duplicated the system, all with the same result, I'm inclined to go with bperrybap's theory that the uno or nano stops and waits for something, thats not going to happen. I don't think is the setup, I don't think it's bad connections or even the sketch, so I'm going to try and play with other libraries or/and using an 8 digit display.
All I want is some basic info to verify it's doing the job. It's just a greenhouse, but I don't want my veg to fry or freeze, dry or drown.
Thanks everybody for their input, ideas and suggestions so far. It might take a few weeks, since I'm a bit swamped at the mo, but I will report back.
Gr Marcel
Get a logic analyzer with USB interface and connect it to the I2C bus to help get a look at what's going on. There are many inexpensive models available and you can download free driver software (PulseView) that contains decoders for many protocols (including I2C).
1 Like
@marcel67
Again, first thing I'd recommend you do is to try to figure out what is happening.
Figure out if the Wire library is locking up.
Put something in your loop() code that does something like blink an LED.
So If that LED stops blinking the code is hung somewhere.
Don't worry about performance that isn't the goal. The goal is to determine what is happening.
Once you identify that there is hang, try to figure out where it is happening.
Did you ever install the hd44780 library and run the I2CexpDiag test?
Also, you have been asked multiple times to post some photos of your setup.
It would be helpful for us to see those.
And for those that think that this potential Wire library lockup issue has been fixed, it really hasn't.
Yes, assuming @marcel67 has a fairly recent IDE version, he could do the proprietary AVR wire library call in his sketch code to turn on timeouts, which would prevent some of the spin loops from hanging, but there would still be issues since the LCD would go bonkers if a timeout does happen because the LCD library does not have the code to recover from a low level i2c issue.
IMO, a better solution to recover from a potential lockup would be to enable watchdog timeouts. That way if the AVR Wire library code does hang, the Arduino watchdog would trigger a reset and everything would be re-initialized and start working again.
That said, the cause of this issue, whatever it is, needs to be identified and if it is a Wire Library lockup, then it is likely a h/w issue that needs to be corrected since if it is a severe issue that constantly causes the lockup, even a watchdog won't be enough get the system working.
--- bill
This the original setup as was in the greenhouse. Still with resistors with the buttons. The open space is where the lcd was. Over the top I have a cover with openings for the buttons, the photoresistor, the lcd screen and the reset-button.
I don't see an LCD in the photo.
--- bill
Sorry Bill, I moved on.
Piccie of the new situation. Need to clean up the wiring and am considering soldering a compacter unit in time.
Replaced the lcd with an 8-bit led display. Works fine , now. Primitive, but I can monitor what's happening under the hood. It displays the measured values (temp, potentio and light) and some of the other parameters. When I have some more time I will test the duplicate setup with your suggested library changes. I'm pretty sure that's where the problem lies.
Marcel
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.