SSDOled won't work for I2C channel

[EAGrahamJr]

I had a completely different display than those listed in core so I'd not paid much attention to the existing classes, but have recently received an OLED that says it's an SSD1306, but only 128 by 32, not 64. It's also I2C, thus

• the constructors create an SPI channel in the parent SsdOled class (e.g. cannot use the I2C channel)
• there are also references to a dcPin and a resetPin, which are not available for an I2C interface
• the height of the 1306 class cannot be set - whether this is required or not is TBD
• goTo is only used in ColourSsdOled and only used to "home" the cursor - the 1306 implementation kinda skipped that

[EAGrahamJr]

I was attempting to tackle this and it got ugly really fast.

• The I2C interfaces typically take a "data" and "command" prefix
• The SPI interface (apparently) uses the dcPin to differentiate
• The constructors got out of hand very quickly trying to preserve the existing structure

These are my thoughts, but since it's not my project and not my API, I will leave it to your discretion:

Recommendations:

• Move the data and command methods to the SsdOledCommunicationChannel objects
  • the SPI implementation would add the dcPin and resetPin devices
  • the I2C implementation would add the command and data prefixes
• Simplify the constructors, e.g.

  SsdOled(SsdOledCommunicationChannel channel, int width, int height, int type)

• Put all of the "initialization sequences" into arrays and send at once, instead of the current one-at-a-time setup

  protected SsdOled(...) {
    this.device = device;
    // init sequence
    this.device.command(getInitializationSequence());
  }
  protected abstract byte[] getInitializationSequence();

• SSD1306 might get a bit tricky because there are two variants: 64 and 32 height
  • there's also a lot of overlap with an SSD1337 which is 128 x 128 (the command set looks to be almost identical, but still working on that)

[EAGrahamJr]

Additional note: since I don't have any of the Colour :grinning: OLED, I won't be able to test any changes against what's already there.

[mattjlewis]

Yes, a tricky one. I recall someone contributed the barebones of the I2C code. I typically use SPI for OLED coms hence cannot personally confirm whether it works or not via I2C. The ones I have could be both SPI and I2C, let me check. Also, it could be related to the fact that it is 128x32 rather than the 128x64 one that I test with.

[EAGrahamJr]

Oh, it definitely is - I'm referring to the CircuitPython drivers and some of the init/offsets are just slightly different.

If you can at least check that I didn't break anything, I think what I'm doing will work.

[EAGrahamJr]

BTW, I was the one that had started the I2C channel.