PeterPan321:
I've also run many tests at this point, banging much more heavily on both my LCD and my RTS, and not once have I even seen a missed read or write, and certainly no lockups. The only exception has been an occasional lockup when I reset the board or upload new code, which causes two resets (never figured out why 2, and don't need to re-open that discussion).
For the AVR based boards that use the DTR signal (some use RTS - which is actually better)
during auto reset the board may actually be getting 3 resets:
- when the host opens the serial port (from using DTR instead of RTS)
- The IDE does one (depending on version of the IDE)
- The "arduino" protocol in avrdude drops DTR and toggles RTS to trigger auto reset before uploading starts
depending the speed of your host, the Arduino may have time to start running in between these.
I suppose there are times when the reset occurs right in the middle of an I2C exchange. I don't expect any improved wire library to be able to fix that, and I can probably live with that if its the only problem case.
If resetting the Arduino creates an I2C issue it is likely to be an issue on the slave side since the Arduino side is completely reset - which is both s/w and h/w.
What is more likely is the possibility that there can be i2c issues at power up (vs reset)
it is possible that if your setup() routine immediately jumps on the i2c bus that the AVR is up and running but the slaves are not because the voltage has to rise up to full vcc level and the AVR can potentially start running sooner than the slaves.
It is also possible that weak pullups are being used on the i2c signals that the i2c signals have not had enough time to fully pull up to vcc.
If possible it is best to put the i2c initialization after other initialization or even put in a 50ms delay to give everything some time to stabilize. The hd44780 library does have a delay in its begin() to avoid any issues like this.
I probably don't have the best HD44780 library. Something written by "Francisco Malpartida". But I'm using it because of all the HD44780 libraries out there, this was the first one where I could get the LCD to do anything with any of their examples. Not saying this would be the case with your library, but it seems people get so deep into making their libraries versatile, they forget to write a complete "getting started" guide to steer a new user through real world setups. Then they further complicate things by putting their ZIP file inside a TAR file, which itself is inside a ZIP.
I'm very familiar with that library as I worked with fm on it for a while.
You should always make sure to download that library from fm's bitbucket site and then do the manual install.
All the released versions of the library are available in zip files.
That library was originally done quite some time ago. Long before there was any sort of library manager in the IDE.
Back then all 3rd party library installations were manual.
The library was done as a LiquidCrystal library replacement. This allowed it transparently replace the bundled LiquidCrystal library with no changes to the sketch code that used LiquidCrystal.
Unfortunately, that now means that it can never use IDE library manager to make installation easier.
I'd like to see your HD44780 library, though you didn't mention whether it uses the original WIRE lib or not (maybe I missed it)?
I created hd44780 to essentially be similar to fm's library only better.
For LCDs that use i2c backpacks it offers a "plug and play" capability by providing auto self configuration.
You don't have to configure the i2c address, pin mappings, or backlight active level. The library figures it out by probing the device.
The hd44780 library internally is quite different from any of the other LCD libraries out there in that it allows the host processor to run in parallel with the LCD. This increases performance as the host is not doing blind delays but only delays when necessary and only the needed amount of time. The host only delays if the host wants to send another command and the previous command has not yet finished.
The hd44780 library can be installed directly from the IDE library manger using the cloud install.
If you install it make sure to read the documentation as it describes the API functions (LiquidCrystal compatible with some extensions) and where to find the examples for each i/o class.
The i/o class for i2c backpacks that use an i/o expander is hd44780_I2Cexp
It also includes a diagnostic sketch I2CexpDiag to test the i2c signals and the LCD internal memory to verify that the library is properly communicating with the LCD module.
Currently, the hd44780_I2Cexp i/o class depends on a Wire compatible library with an object named "Wire".
It can be made to work with software i2c libraries by simply declaring an i2c object named Wire.
I have tested this with a couple soft i2c libraries.
The downside of this is that you can't use the hardware Wire library for some slaves and then a soft i2c library for hd44780 because of this limitation.
I'm looking at doing a re-factoring of the library to make things much better.
(or perhaps a new simpler library that is just for LCDs with PCF8574 backpacks which would reduce the code size as well)
In the future the sketch will be able to specify the name of the i2c library object.
So as long as the object provides a Wire library compatible API, the user will be able to use any i2c object.
This is the way things should work and will once and for all solve the issue of i2c libraries and using multiple i2c buses.
It requires using a templated C++ class which uses a different structure than nearly all Arduino libraries are using today (all code must be in the .h file and no .cpp file)
hd44780 is already mostly doing this so moving all the way to allow templating is the next step.
--- bill