bperrybap:
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
I've actually pulled out a magnifier (and a glass of wine to steady my aging hands) and removed the .1 uF capacitor between the USB chip's DTR pin and the CPU's reset, soldered on a tiny pair of wires, and ran it out to a small switch with its own capacitor, and glued the switch to the board. Its just handy to be able to turn it off when I just want to turn on the built in or external serial monitor, so I can look at logs and debugs without resetting.
bperrybap:
depending the speed of your host, the Arduino may have time to start running in between these.
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)
Although I never got such a lockup until I added the RTC and LCD together to the project, one of the things you're suggesting is probably true. Since I've discovered these cheap LCDs, I have a tendency to immediately "light it up" to display some kind of scrolling start up message. So when I upload code, and the multiple resets begin, its pretty likely I'll get interrupted mid way through displaying some eye candy on the LCD. I do have a 4 button keypad on my current project though, and it requires NO I2C ;-). So maybe it would be wise for me to make this, and other I2C projects hold off on doing anything until I press the "any" key. It would be interesting to see if that completely eliminates this kind of issue.
bperrybap:
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.
Can you share a direct link to it?
Also, considering the small code space available in these Arduinos, isn't it better to let address discovery scan be a separate app, and then just import the LCD's discovered I2C address into your code? Besides the wasted code space, it has to get tedious and convoluted to both "discover" I2C addresses, while simultaneously rejecting non-LCD addresses (RTCs, digital POTs, etc).
bperrybap:
The hd44780 library can be installed directly from the IDE library manger using the cloud install.
I see it in the LIb manager. I think you pointed it out to me in another thread when I was first polink around and trying to get my LCDs at least to a working "Hello World" state.
bperrybap:
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)
Ah... refactoring! I sorely miss being able to do all my development in Eclipse, if only for that wonderful capability.
But I'd definitely recommend you DO make such an I2C backpack only version. I know a lot of forums try to steer people toward direct interface with the HD44780, the Arduino has a limited number of I/O lines and CPU time, has no tread or task management, and for my money LCD is THE way to go. Exception, of course, if you're talking to an LCD with graphic capability where you really need absolute max speed. But for character display, I2C is plenty fast enough. I've even been able to switch out characters on the fly for better bar graphs, just with I2C. (As in this, my current project, by the way... Solar ONE! - An all in One Pool Pump Controller for Solar Heated Pools). And I don't have tell you that these displays, along with I2C backpacks, have become dirt cheap.
My final argument, of course, is that any substitution of WIRE functionality with a different I2C library will obviously be much easier, if everything is limited to a simple file.
By the way, I don't use templates a LOT, but I too like to write my classes so that everything is in the .H. file. If a few constants,r shared vars or statics need to be declared, its plenty easy to just use #ifdef to ensure no duplicate objects, right?
Anyway, good talking with you!