Beau Schwabe I have never seen something like that ever. I just don't know how it could possibly work. I sincerely ask whether or not you have ever done that implementation, even bit banging, and had that work. I would be both amazed, stand corrected, tip my hat (if I wore one) and vow to start thinking further out of the box. I would also doubt my understanding of I2C (not that I think I am an expert in that area), and punish myself by having to re-read that Phillips pub and much more.
If you ask me, "why not"? My head will start hurting because I know that both I2C lines are bi-directional (ok, maybe without clock stretching, you could make SCL unidirectional) and I think you would have all sorts of problems. But, maybe I am wrong and that is why I am asking if you have ever successfully done that.
Nevertheless, I think that the *best* solution has already been offered and here is my reasoning, which I offer for critical review.
The OP is using a cheap display. There have been reports of problems with cheap displays not ACKing (see
https://github.com/olikraus/u8g2/issues/192 for example, but just search for problems with SH1106 OLED .
I am assuming that the OP has such a display.
I am also assuming that the OP can not, or does not want, to write his own I2C routines.
Using a software definition for a separate set of pins will likely work, or at least should be tried. Yes, it will slow down the display - how important is that?? It was suggested that the dPOT could be used on a separate set of pins. I don't disagree, but that would mean writing his own I2C routines for the dPOT and not use wire.
Now, it is possible that my first assumption is wrong and that it is
not simply that the display doesn't ACK (as someone mentioned, I too have used several SSD1306 OLEDs with I2c and multiple devices and never had a problem.
Look again at this exchange:
https://github.com/olikraus/u8g2/issues/192 The OP there states, "
The SSD1306/SH1106 controller supports two I2C addresses (0x3C/0x3D [or 0x78/0x7A as marked on the generic Chinese displays]), with 0x3C/0x78 being the default.."
Remember, the OP has stated that the scanner finds the dPOT at 0x3c and he has also stated that the display is marked as using 0x78.
The author of the display library has posted here
https://github.com/olikraus/u8g2/wiki/u8g2reference#seti2caddress ...
That U8G2 uses the LOWEST display address by default and this would cause a conflict with the dPOT. There is a remedy, however, see
https://github.com/olikraus/u8g2/wiki/u8g2reference#seti2caddress by using void u8g2_SetI2CAddress(u8g2_t *u8g2, uint8_t adr)
Alternatively, the dPOT address can be easily changed.
That's how I see it anyways.