OLED Display using U8x8 library - hardware vs software SPI

Other Hardware Displays
1

I have a DFRobot 0.96" 128x64 Pixel Display (DFR0650). I hadn't realised that these displays were so slow and was investigating ways to speed things up. I'm using 4-wire SPI instead of I2C and I've checked that hardware SPI is set to the maximum clock speed on an UNO (8 MHz).

I'm using the U8g2 library and as expected the U8x8 character only mode is faster than page mode in U8g2.

What is confusing me is that software SPI is approximately 7 times faster than hardware SPI. I was not expecting that. Does anyone know why this might be the case?

In case I have made some stupid programming mistake I have included the test sketch below. The only change between software and hardware SPI is the u8x8 constructor.

#include <Arduino.h>
#include <U8g2lib.h>

#include <SPI.h>

#define MOSI  11
#define DC    9
#define SCK   13
#define CS    14

#define SAMPLE_TIME 1000  //  1 second = 1000 ms

U8X8_SSD1306_128X64_NONAME_4W_HW_SPI u8x8(CS, DC);
//U8X8_SSD1306_128X64_NONAME_4W_SW_SPI u8x8(SCK, MOSI, CS, DC);

char freqAsChar[6];
bool toggle = false;
int loopCounter = 0, loopFrequency = 0;
unsigned long startTime, currentTime;

void setup(void) {
  u8x8.begin();
  startTime = millis();
}

void loop(void) {
  currentTime = millis();
  loopCounter++;
  u8x8.setFont(u8x8_font_chroma48medium8_r);

  if (toggle) {
    u8x8.drawString(15, 1, "*");
  }
  else {
    u8x8.drawString(15, 1, " ");
  }

  if (loopFrequency > 0) {
    u8x8.drawString(0, 6, "LOOP FREQ: ");
    itoa(loopFrequency, freqAsChar, 10);
    u8x8.drawString(10, 6, freqAsChar);
    u8x8.drawString(14, 6, "HZ");
  }

  if (currentTime - startTime >= SAMPLE_TIME) {
    toggle = !toggle;
    loopFrequency = loopCounter;
    loopCounter = 0;
    startTime = currentTime;
  }
}
2

I don't know how slow is slow for you. With my OLED I use the "SSD1306Ascii" library. It is character only, no graphics.

I've found positioning the "cursor" so the minimum number of characters makes the display much faster.

If you clear and rewrite everything on each write it gets slower.

My test code is:

// Device Test Code
//  OLED 128 x 64 and 128 x 32
//  Greiman SSD1306Ascii Library
//
//
// 2022-03-14
//
//
//

#include <Wire.h>

#include "SSD1306Ascii.h"
#include "SSD1306AsciiWire.h"

#define OLED_ADDRESS 0x3C


SSD1306AsciiWire oled;  // create OLED object

void setup(){

  oled.begin(&Adafruit128x32, OLED_ADDRESS);
  oled.setFont(CalLite24);          // this brings in CalLite24.h allowing us access "CalLite24_WIDTH"
  oled.displayRemap(true);          // rotate text 180°
  oled.clear();
}


void loop(){

  oled.SSD1306Ascii::setCursor(0,0);
  oled.print(riseTime);
  oled.print("  ");
  oled.print(fallTime-riseTime);

  delay(2500);

}  //  -- end of loop --

//   oled.SSD1306Ascii::setCursor(Column,Row);
//   oled.SSD1306Ascii::setCursor(8*13,4);

//  Rows are:  0, 2, 4, 8  or 128 x 64 Oled with 4 rows.
//  Columns are:  column number * font width
/*

    oled.SSD1306Ascii::setCursor(1*8,0);
    oled.clear()
    oled.print(temp,1);
    oled.setFont(ZevvPeep8x16);


    oled.set2X();
    oled.set1X();

    clearToEOL()  {clear(m_col, displayWidth() -1, m_row, m_row + fontRows() - 1);


//------------------------------------------------------------------------------
uint8_t SSD1306Ascii::fontHeight() const {return m_font ? m_magFactor*readFontByte(m_font + FONT_HEIGHT) : 0;}
uint8_t SSD1306Ascii::fontRows() const {return m_font ? m_magFactor*((readFontByte(m_font + FONT_HEIGHT) + 7)/8) : 0;}
uint16_t SSD1306Ascii::fontSize() const {return (readFontByte(m_font) << 8) | readFontByte(m_font + 1);}
uint8_t SSD1306Ascii::fontWidth() const {return m_font ? m_magFactor*readFontByte(m_font + FONT_WIDTH) : 0;}
const uint8_t* font() const {return m_font;}

// setCursor(x, y) is pretty much the standard way to set the cursor in a graphics library. It allows you to position to the finest address on the display.

*/
3

Hi @JohnRob - thanks for the response.

To be specific, using u8g2 page mode, with hardware SPI I was measuring a loop frequency of 15 Hz. That's what I consider slow!

Using u8x8 character's only with hardware SPI the loop frequency increases to 120 Hz and for software SPI it was 778 Hz - which isn't too bad.

I'll give your library a go and see how that compares.

What is really confusing me is the fact that software SPI is faster than hardware SPI. I was expecting it to be the other way around.

4

@olikraus may be able to suggest a reason?

5

I tested the SSD1306Ascii library. It works differently to u8g2 and u8x8 but using software SPI I got a loop frequency of around 25 Hz (so faster than u8g2 page mode but slower than u8x8, which is a better comparison).

I then tried your suggestion regarding setCursor() instead of clear() and you are correct, it is much faster, the loop cycle frequency increases to 100 Hz.

6

15 Hz refresh rate in u8g2 page mode should be a good value for the Arduino Uno.

What is confusing me is that software SPI is approximately 7 times faster than hardware SPI.

For u8g2 or u8x8? How did you measure this?

Actually I have never seen that SW SPI is faster than HW SPI on a proper configured Arduino Environment. Do you use any custom Environment with your Uno@8Mhz?

Oliver

7

Hi Oliver - thanks for the quick response and for writing the library!

I haven't made any changes to the UNO environment. The comparison is for u8x8. I measured it using the sketch in the original post, results shown on the OLED display. The only thing I change is the constructor.

8

I have tested your code with an Arduino Uno @ 16MHz.

HW SPI: 2444 Hz
SW SPI: 1638 Hz

So: SW SPI is slower than HW SPI on my board.

Oliver

9

The SPI bus is only used to write to the display ? Could I can run it in a simulation that does not have a SPI display ? If so, then I can confirm that software SPI is slower.

I tried the sketch in the original post in Wokwi simulation, and the hardware SPI was faster for a 16MHz Uno.
Then I reduced the sketch, and once again, the hardware SPI was faster.

// For: https://forum.arduino.cc/t/oled-display-using-u8x8-library-hardware-vs-software-spi/1053666/
// This Wokwi project: https://wokwi.com/projects/348382129617371731

#include <SPI.h>
#include <U8g2lib.h>

#define MOSI  11
#define DC    9
#define SCK   13
#define CS    14

#define SAMPLE_TIME 1000  //  1 second = 1000 ms

U8X8_SSD1306_128X64_NONAME_4W_HW_SPI u8x8(CS, DC);
// U8X8_SSD1306_128X64_NONAME_4W_SW_SPI u8x8(SCK, MOSI, CS, DC);
// U8X8_SSD1306_128X64_NONAME_HW_I2C u8x8(U8X8_PIN_NONE);
// U8X8_SSD1306_128X64_NONAME_SW_I2C u8x8(SCL, SDA, U8X8_PIN_NONE);

unsigned int loopCounter = 0;
unsigned long startTime;

void setup(void) {
  Serial.begin(115200);
  u8x8.begin();
  u8x8.setFont(u8x8_font_chroma48medium8_r);

  startTime = millis();
}

void loop(void) {
  unsigned long currentTime = millis();
  loopCounter++;
  
  // speed test by writing text to the display
  u8x8.drawString(0, 0, "Hello World");

  // one second millis timer
  if (currentTime - startTime >= SAMPLE_TIME) {
    startTime = currentTime;
    Serial.println( loopCounter);
    loopCounter = 0;
  }
}

This sketch in Wokwi: OLED_SPI.ino - Wokwi ESP32, STM32, Arduino Simulator

Results (number of iterations per second):

SPI hardware : 419 (no display connected)
SPI software : 268 (no display connected)
I2C hardware : 99
I2C software : 10

Those numbers make perfect sense and are what is expected.
A software I2C bus can be faster than a hardware I2C on a Arduino Uno with optimized code and reduced overhead and ignoring some I2C timing, but it is according to the speed tests that I did in the past.

10

Thanks guys - I would expect hardware SPI to be quicker than software.

Interesting that you get different results runninng the same sketch. I think my UNO is a clone, I'll see if I can find a genuine Arduino in my collection.