MCP45HVX1 Digital POT and SH1106 OLED Display both on I2C

[Pommie]

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.

 

[Beau Schwabe]

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.

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.

 

[DrG]

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.

 

[gophert]

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

 

[DrG]

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

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

 

[dr pepper]

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.

 

[Pommie]

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.

 

[riccardo]

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.

 

[riccardo]

Erm...

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

 

[Nigel Goodwin]

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

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.

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.

 

[Pommie]

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

Mike.

 

[riccardo]

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

However..

u8g2reference

U8glib library for monochrome displays, version 2 - olikraus/u8g2

github.com

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

I wonder what 0x78 / 2 is

 

[riccardo]

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.

 

[Nigel Goodwin]

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.

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.

 

[Pommie]

Congratulations, perseverance paid off.

Mike.

 

[DrG]

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.

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.

 

[DrG]

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.

https://ww1.microchip.com/downloads/en/DeviceDoc/20005304A.pdf

Section 6.2.4 Figure 6.9

 

[Nigel Goodwin]

Page 51

 

[DrG]

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

Mike.

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.

 

[Pommie]

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

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.