Allow changing display type via Menu

[alextrical]

Hi all

I was wondering if anyone has any advice on switching between a SSD1306 and SH1106 display type via a option in the menu without requiring a rebuild with the variables set for a different display type?

Many thanks

[davetcc]

Hi there, assuming you’re using U8G2, at least from a high level there is a different class for each display type. You could probably do it by creating the display variable yourself using the custom u8g2 plugin maybe using new to create them on demand. But To be honest it’s not something I’ve really considered this far.

[davetcc]

One option is to produce a plugin for it, if you need it soon, you could have a go yourself, it is actually fairly well-documented and doesn't need a full developer environment. You could probably start with one of the others, the simplest one, and try that.

https://github.com/davetcc/tcMenu/tree/master/xmlPlugins

and here is a fairly simple example

https://github.com/davetcc/tcMenu/blob/master/xmlPlugins/core-display/dfRobotLcd.xml

[davetcc]

There's even an another option that will create a custom drawable for you as well, it will basically implement the drawable that should interface with the display on your behalf, leaving you to just implement the glue layer basically. It will leave a few gaps, but should be quite straightforward.

[alextrical]

That's ideal, i will take a look over the documentation tomorrow and see what I can achieve with it.
I never expect someone have to build something for me, all I hopefully need is some hints when i get stuck. Thank you for your help, and a great project to build menus with

[davetcc]

I’d be up for even writing it longer term, but there are a few stability issues in 3.0 that need addressing first.

If you raised an issue with examples of the libraries use and links I would try and fit it into 3.2 or 3.3 depending on how easy it was.

[alextrical]

I have managed to get an example of the code for u8g2 to detect the display type present (at a defined address) and then select the correct class based on that information.

So far it allows attaching a SSH1306 or SH1106 without the graphical glitch associated with using the wrong class type. But it will definitely help the users of the projects I'm working on, when sellers interchangeably send one or the other chipsets out.

I will draft up an issue now, and hopefully this will be a feature useful to other users in the future too. (if a bit niche)

#include <Wire.h>

U8G2_SSD1306_128X64_NONAME_F_HW_I2C u8g2_1(U8G2_R0, /* reset=*/U8X8_PIN_NONE);  //SSD1306 Type1
U8G2_SH1106_128X64_NONAME_F_HW_I2C u8g2_2(U8G2_R0, /* reset=*/U8X8_PIN_NONE);   //SH1106 Type2
U8G2 *u8g2;

void setup() {
  Wire.begin();

  if (isSSD1306(0x3C)) {  //SSD1306
    u8g2 = &u8g2_1;
  } else {
    u8g2 = &u8g2_2;
  }
  
  u8g2->begin();
}

void loop() {
  u8g2->firstPage();
  do {
    u8g2->setFont(u8g2_font_ncenB10_tr);
    u8g2->drawStr(15, 24, "Hello World!");

    //Show the display type
    if (isSSD1306(0x3C)) { //Address of the display to be checked
      u8g2->drawStr(32, 48, "SSD1306!");
    } else {
      u8g2->drawStr(35, 48, "SH1106!");
    }

  } while (u8g2->nextPage());

  delay(1000);
}

bool isSSD1306(int address) {
  byte buffer[0];

  Wire.beginTransmission(address);
  Wire.write(0x00);
  Wire.requestFrom(address, 1);  // This register is 8 bits = 1 byte long
  if (Wire.available() > 0) {
    Wire.readBytes(buffer, 1);
  }
  Wire.endTransmission();

  buffer[0] &= 0x0f;        // mask off power on/off bit
  return buffer[0] == 0x6;  //0x3 = SSD1306 128x32, 0x6 = SSD1306 128x64, 0x7 || 0xf = SH1107, 0x8 = SH1106
}```