LCD I2C in digital pins

Other Hardware Displays
1

I'm using I2C to communicate with the LCD display. As A4 and A5 are connected to the I2C pins I run out of analogy ports. Therefore I want to use alternative digital pins. Is this possible? How can I use softI2C library and liquidcrystal_i2c together?

2

Use a Nano - in case you are not doing so already - you have two more analog pins,

3

I'm using an Uno - as I also need a couple of digital pins....

4

The Nano has two more - analog only - pins than the "standard" UNO. And a more practical form factor.

5

NickAmSee:
How can I use softI2C library and liquidcrystal_i2c together?

You can use the hd44780 library and the hd44780_I2Cexp i/o class with the SoftwareWire library.
However, while it will work for all your sketches, you will not be able to use the I2CexpDiag sketch that comes with the hd44780 library to test things as it assumes that the LCD device is connected to the standard SDA and SCL pins.

Both the hd44780 and the SoftwareWire library are available in the IDE library manager.

Here is an example sketch that shows how to use them together:

#include <SoftwareWire.h> 
const int sda=A0, scl=A1; // use any pins you want for sda and scl
SoftwareWire Wire(sda,scl); // declare the SoftwareWire object

#include <hd44780.h>
#include <hd44780ioClass/hd44780_I2Cexp.h>
hd44780_I2Cexp lcd; // declare lcd object and let it auto-configure everything.

void setup()
{

  int istatus = lcd.begin(16,2);
  if(istatus)
  {
	// LCD initalization failed.
	// handle it anyway you want

	lcd.fatalError(istatus); // blinks error on built in LED
  }
  lcd.print("Hello, World!");
}

void loop() { }

It won't be as quite fast as using the i2c h/w but it still works very well.

--- bill

6

bperrybap:
It won't be as quite fast as using the i2c h/w but it still works very well.

Indeed, it absolutely should work perfectly because I2C is a strictly master-slave protocol clocked by the master which can delay to any reasonable (or perhaps even, unreasonable) extent required. :astonished:

There should be no errors in the implementation.

7

Paul__B:
Indeed, it absolutely should work perfectly because I2C is a strictly master-slave protocol clocked by the master which can delay to any reasonable (or perhaps even, unreasonable) extent required. :astonished:

Perhaps my wording of "works very well" was ambiguous. I meant from a performance/usability viewpoint:
i.e. the s/w i2c is fast enough to not really be noticeable in terms of display output. (at least when using hd44780).

There should be no errors in the implementation.

It is possible, but if I were to bet money on it, I would bet that there are likely some issues for corner cases.
No way of knowing with out some extensive testing.
Fully testing things like slave clock stretching, and multi-master takes some specialized tools and/or h/w to do proper testing.

I've experienced implementation issues with several Wire libraries, including the IDE bundled Wire library with the AVR core, and the chipkit Wire library that caused the library to lockup.
For example even today, under certain conditions the AVR Wire library can be made to lock up as it is not properly handling certain slave and/or multi-master END bit sequences.
It is a s/w issue as the AVR i2c state/protocol implementation is mostly implemented in s/w.
The s/w gets stuck waiting for event that never happens, and has no timeout so it waits indefinitely.

--- bill

8

I'll solve it the other way round and add a AD I2C Converter. So i'll have the additional analog ports without using digital ports

9

NickAmSee:
I'll solve it the other way round and add a AD I2C Converter. So i'll have the additional analog ports without using digital ports

I didn't mean to scare you off of using the SoftwareWire to allow using the digital ports for I2C.
I've used SoftwareWire a bit and for the typical usage case of a single master and slaves that don't mis-behave, it seems to work well.

--- bill