u8g2, I2C and VirtualWire

I’m looking for ideas what to investigate next to iron out a problem with slow I2C in OLED updates using the U8x8 subset of u8g2 lib. I am using hardware I2C on A4/A5. My project is functioning correctly on an 8mhz pro-mini, but the OLED updates are super slow. On my scope I can see SCL running at about 5KHz. Part of the problem is an interaction with VirtualWire, which probably dinks with a prescaler that controls I2C, and if I remove VirtualWire entirely, I can see the SCL running at about 10KHz. This is still about 1/10 the speed it should be.

Setting u8x8.setBusClock(100000L) doen’t seem to make any difference no matter what speed I ask for.

Some relevant parts of my sketch:

#include <U8x8lib.h>

#ifdef U8X8_HAVE_HW_SPI
#include <SPI.h>
#endif

/* The display is on the hardware I2C pints
 *   SCL --> A5,  SDA --> A4
 */
U8X8_SSD1306_128X32_UNIVISION_SW_I2C u8x8(SCL, SDA, U8X8_PIN_NONE);

void setup(void)
{
  
  u8x8.begin();
  u8x8.setBusClock(100000L);
  u8x8.setPowerSave(0);
  u8x8.setFont(u8x8_font_chroma48medium8_r);
  u8x8.setContrast(100);
}

    u8x8.drawString(0,0,"Lk");

I stuck the whole thing as an attachment, if anyone cares to look.

Thanks for any/all ideas.

Test_OLED.ino (9.82 KB)

Duh. I figured this out: I was using

U8X8_SSD1306_128X32_UNIVISION_SW_I2C

and should have been using

U8X8_SSD1306_128X32_UNIVISION_HW_I2C

I understood that the hardware vs software I2C was figured out from the pins, but it’s a different constructor. I’d been using the SW one. Duh.

Hardware I2C runs at the speed I ask it to and AFAICT VirtualWire is okay.