MKS 12864OLED Display setup

Question

I've bought MKS 12864OLED and connected to my DIY 3d printer with Mega/RAMPS combination. In Marlin's configuration.h file there are these lines to uncomment:

// MKS OLED 1.3" 128 × 64 FULL GRAPHICS CONTROLLER
// http://reprap.org/wiki/MKS_12864OLED
//
// Tiny, but very sharp OLED display
//
//#define MKS_12864OLED          // Uses the SH1106 controller (default)
//#define MKS_12864OLED_SSD1306  // Uses the SSD1306 controller

I'm not sure to choose between 'SH1106' or 'SSD1306'... either way, the LCD module is not working.

Answer 1

First of all let me state that I do not own the module! The analysis below is based on old patches that worked in a version of Marlin in 2015, and translated to the latest version of Marlin of the 1.1.x branch. This is 1.1.9; this is the last version of the 1.1.x branch, all new development takes place in branch bugfix-2.0.x (dated May 2019).

---

The reported patches are compatible with an earlier version of Marlin Firmware (a version from 2015). Clearly this doesn't work anymore, but that should not be a problem, if it worked then it should work now provided we configure it correctly. The display you have requires U8GLIB_SSD1306, so the U8GLIB library need to be installed in your Arduino IDE!

Let's follow this installation guide for the older version as an example.

First, from patch 1 it becomes clear that you'll need to define that you are using a display that is identified by its name/type, you should uncomment the following line in your configuration.h in the section:

//=============================================================================
//======================== LCD / Controller Selection =========================
//========================   (Character-based LCDs)   =========================
//=============================================================================

//#define MKS_12864OLED_SSD1306  // Uses the SSD1306 controller

to:

#define MKS_12864OLED_SSD1306  // Uses the SSD1306 controller

as you are using the SSD1306 controller according to this reference.

That is about the only thing you add in the configuration.h file! You only activate the name of the controller type (as in defining a constant) so that it is caught in other source or header files to do/trigger something.

With this change, you automatically activated the rest of patch as that is implemented in Conditionals_LCD.h!

Next, we need to address patch 2. This is addressed in ultralcd_impl_DOGM.h; here you will find:

#elif ENABLED(MKS_12864OLED_SSD1306)
  // MKS 128x64 (SSD1306) OLED I2C LCD
  U8GLIB_SSD1306_128X64 u8g(DOGLCD_SCK, DOGLCD_MOSI, DOGLCD_CS, DOGLCD_A0);      // 8 stripes
  //U8GLIB_SSD1306_128X64_2X u8g(DOGLCD_SCK, DOGLCD_MOSI, DOGLCD_CS, DOGLCD_A0); // 4 stripes

which clearly differs from the patch:

U8GLIB_SSD1306_128X64 u8g(23, 17, 16, 25); // SW SPI Com: SCK = 23, MOSI = 17, CS = 16, A0 = 25

as such that it uses numbers instead of constants. So we need to define these constants first. These constants are defined by the board you are using, more specifically the pin layout.

Looking at the pin layout of your RAMPS board:

      #if ENABLED(MKS_12864OLED) || ENABLED(MKS_12864OLED_SSD1306)
        #define LCD_PINS_DC     25   // Set as output on init
        #define LCD_PINS_RS     27   // Pull low for 1s to init
        // DOGM SPI LCD Support
        #define DOGLCD_CS       16
        #define DOGLCD_MOSI     17
        #define DOGLCD_SCK      23
        #define DOGLCD_A0       LCD_PINS_DC

you'll find that the pins are correctly configured with the fore mentioned:

U8GLIB_SSD1306_128X64 u8g(DOGLCD_SCK, DOGLCD_MOSI, DOGLCD_CS, DOGLCD_A0);      // 8 stripes

We move on to patch 3. This patch deals with the reset/initialization of the OLED display. This is also already taken care of in ultralcd_impl_DOGM.h:

  #if PIN_EXISTS(LCD_RESET)
    OUT_WRITE(LCD_RESET_PIN, LOW); // perform a clean hardware reset
    _delay_ms(5);
    OUT_WRITE(LCD_RESET_PIN, HIGH);
    _delay_ms(5); // delay to allow the display to initalize
  #endif

Next to patch 4, in pins_RAMPS.h you see that pin 25 and 27 are correctly defined (apart from the name LCD_PINS_RST, now without T, but that is fine!):

  #if ENABLED(MKS_12864OLED) || ENABLED(MKS_12864OLED_SSD1306)
    #define LCD_PINS_DC     25   // Set as output on init
    #define LCD_PINS_RS     27   // Pull low for 1s to init

The only difference is that pins

    #define LCD_PINS_D5
    #define LCD_PINS_D6

are not set to -1, so to be consistent, you should change pins_RAMPS.h to:

      #if ENABLED(MKS_12864OLED) || ENABLED(MKS_12864OLED_SSD1306)
        #define LCD_PINS_DC     25   // Set as output on init
        #define LCD_PINS_RS     27   // Pull low for 1s to init
        // DOGM SPI LCD Support
        #define DOGLCD_CS       16
        #define DOGLCD_MOSI     17
        #define DOGLCD_SCK      23
        #define DOGLCD_A0       LCD_PINS_DC
        #define LCD_PINS_D5     -1
        #define LCD_PINS_D6     -1
      #else
        #define LCD_PINS_RS     16
        #define LCD_PINS_ENABLE 17
        #define LCD_PINS_D4     23
        #define LCD_PINS_D5     25
        #define LCD_PINS_D6     27
      #endif

A conclusion from the analysis above is that you enable the display in your configuration file and add the 2 values of -1 for D5 and D6, but I don't think they cause problems if they're not initialized to -1. Be sure that the cables are connected correctly. Some modules have reported upside down connectors.