MCP45HVX1 Digital POT and SH1106 OLED Display both on I2C

If the data line goes low without the clock line then all devices see a start condition. Can't work out if that would be a problem.

Mike.

Pommie said:

If the data line goes low without the clock line then all devices see a start condition. Can't work out if that would be a problem.

Mike.

Click to expand...

The "other" device will never recognize the I2C address, so it will ignore the data and simply not respond. .... Think of it as a "Chip Enable" as mentioned earlier in this thread.... only you acomplish it by swapping the SDA and SCL on just one of the I2C devices in this case.

I looked at my display parts and I do have a 1.3", I2C 128X64 SH1106 OLED - this one. I have never used it in a project but, as is my practice, I checked it out when I got it and made some notes. Among those notes was "I2C address=0x3c"

Look at the link and notice the resistor and address info...the 0x78 that is printed on the back of the display. Mine looks exactly like that, including the position of the resistor (0 ohm?). This is also what the OP reports.

I just verified that it works (UNO clone) using the U8G2 library and this constructor line:
U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2(U8G2_R0, /* reset=*/ U8X8_PIN_NONE);

I ran several demo programs with no problem and no other devices present. I do have some dPOTS but none with I2C interfaces.

I used a run-of-the-mil port scanner and it reported only a device at 0x3c (just as my notes had indicated). riccardo , please humor me and run a port scanner with the display but without the dPot connected and see if you do not also see a device at 0x3c.

If so, I suggest that you set A0 and A1 to change the dPOT I2C address so that it does not conflict with the display.

I now think that the issues that the OP has experienced may be a simple address conflict and the usual misinformation that comes with cheap electronics.

The Wire.write() command needs data type BYTE. In the code, the variable "value" is an int.

gophert said:

The Wire.write() command needs data type BYTE. In the code, the variable "value" is an int.

Click to expand...

It gets typecast - see Wire.h, e.g, inline size_t write(unsigned int n) { return write((uint8_t)n); }

Swapping the lines might well work, you might have to send the first byte twice or send a dummy command to clear any framing errors.
It'd confuse the heck out of someone tracing the wiring trying to copy it.

Looking at the MCP datasheet, I can't find any reference to the I2C address. Am I going blind or is that considered superfluous information these days?

Mike.

My digipot is fixed on the PCB, so that one is stuck with he hardware I2C. Screen being on a cable gives me the option to connect it elsewhere. Glad I connected some solder pads to unused pins on the micro just in case!

I used SetI2CAddress and experimented with different addresses just to make sure. The OLED is definitely only working when addressed at 0x78
(EDIT: Nope. when I used SetI2CAddress(0x78) command, this actually addresses 0x3C)

The code here is a minimal sample to test the I2C problems. The end program will be part of a bigger more complex system.

Looks like software I2C for the OLED will be the way to go. I will try this out today hopefully.

Regarding the cheap OLED: Where can I find good ones? (UK supplier preferably) There's so many on sale but they all look to be basically the same.

Erm...

Weird. I used the set address command set to 0x3C and the display didnt work. When I set to 0x78, it worked!

riccardo said:

Looks like software I2C for the OLED will be the way to go. I will try this out today hopefully.

Click to expand...

Why for the OLED?, the OLED could do with been fast as you're moving a fair amount of data to amke it work (it's a bit mapped screen) - whereas the digital pot is a very slow device and transfers little data anyway.

Regarding the cheap OLED: Where can I find good ones? (UK supplier preferably) There's so many on sale but they all look to be basically the same.

Click to expand...

They all come from China anyway, if you can find a UK supplier they will simply be buying them from China and applying a decent profit margin for themselves - so same item, much higher price, but faster delivery.

I tend to use Banggood or Aliexpress, often Aliexpress is alot cheaper than Banggood.

So, why doesn't the I2C scanner find the LCD at 0x78?

Mike.

Nigel: The digipot is a small SMD part fixed to the PCB, so trying to swap its I2C lines is not easy.

However..

"I2C address multiplied with 2 (the lowest bit must be zero)"

I wonder what 0x78 / 2 is

And now it works! I changed the address jumper on the OLED to 0x7A (Which is really 0x3B)

Thank you all so much for your help. It is greatly appriciated!

The solution in the end is simpler than I had even hoped, and I have learned lots of useful thins along the way. Thank you again everyone.

For any googlers turning up here looking why the SH1106 OLED etc or ug8lib wont work with their other I2C devices the solution is.

Don't trust the spec the Chinese give you. Scan for the address. Read the bit in the u8g2 library that says the byte supplied for address must be the address multiplied by 2. Not sure why they don't just multiply by 2 in the library so you can pass the actual address, but oh well, it works.

riccardo said:

And now it works!

Thank you all so much for your help. It is greatly appriciated!

The solution in the end is simpler than I had even hoped, and I have learned lots of useful thins along the way. Thank you again everyone.

For any googlers turning up here looking why the SH1106 OLED etc or ug8lib wont work with their other I2C devices the solution is.

Don't trust the spec the Chinese give you. Scan for the address. Read the bit in the u8g2 library that says the byte supplied for address must be the address multiplied by 2. Not sure why they don't just multiply by 2 in the library so you can pass the actual address, but oh well, it works.

Click to expand...

It's always a good idea to scan for the address, but you can't blame the library, it's how the I2C spec works - and I agree it's confusing, I've also fallen foul of forgetting to either double or half the address.

Congratulations, perseverance paid off.

Mike.

Nigel Goodwin said:

They all come from China anyway, if you can find a UK supplier they will simply be buying them from China and applying a decent profit margin for themselves - so same item, much higher price, but faster delivery.

Click to expand...

Yes, you are absolutely correct about that, but....If you purchase from a higher end place, say for example Adafruit or an eMicro Click board or even Newhaven I believe that you get better quality control and much better support. By support, I don't necessarily mean that you call them to fix your problem, I mean documentation and "legwork" that has already been done.

I too have bought a few from Bangood and noname eBay sellers...it is sometimes an adventure and great learning experience...if that is what you want.

Pommie said:

Looking at the MCP datasheet, I can't find any reference to the I2C address. Am I going blind or is that considered superfluous information these days?

Mike.

Click to expand...

Section 6.2.4 Figure 6.9

Page 51

Pommie said:

So, why doesn't the I2C scanner find the LCD at 0x78?

Mike.

Click to expand...

The I2C device address is 7 bits. An 8th bit is a R/W (1/0) bit. If you label it as an I2C address, you get the problem of whether it is labelled "shifted" or not. 78' is shifted is 3C.

**broken link removed**

from https://www.totalphase.com/support/...it-8-bit-and-10-bit-I2C-Slave-Addressing#7bit

In the example illustrated, you can see what I mean.

And BTW, I should have seen that problem way sooner...it's like I have to retrain myself regularly...rather annoying, but I am glad that the OP got it fixed.

DrG said:

And BTW, I should have seen that problem way sooner...

Click to expand...

We all should. Having mainly used pics in the past where the unshifted address is used, it never occurred to me that the Arduino uses shifted addresses (sometimes).

Mike.