XIAO SSD1306/1315 SPI - Is it possible?

Hi all,

New to Seeeduino, but have been playing around with a few other brands in the past two years.
Unfortunately boards that didn’t need the use of Arduino, which makes it irritating to find that I just can’t get my head around this.

I’m trying to connect an OLED display with SSD1306 drivers - it’s actually a SSD1315, but it’s basically the same thing. I’ve tried the SSD1315 drivers as well, but the result was the same.

I can successfully connect an I2C display to the Xiao, but using the SSD1315 SPI is making my head spinn. I can’t get it to work. It’s also stated that the SSD1315 is supposed to be able to connect via I2C, but that didn’t go very well either.

I’m doing it right with the SSD1306 I2C OLED Display, but the SSD1315 SPI/I2C is pure evil.

Anyone got the SSD1306 (or 1315) SPI drivers to work? Or 1315 I2C for that matter?

I’ve connected the evil little thing in most way I could find, but nothing. Well almost nothing.
I managed to get the SSD1315 connected as I2C to be recognized by Arduino when scanning for I2C devices.

The only time I get the recognition is when I’m connecting SCL to D0 and SDA to D2 (nothing else connected at this point - except for the VCC and GND ofcourse). at this stage I get a response that both the address 0x00 and 0x01 has I2C devices attached.

Connecting an I2C SSD1306 OLED display to PIN A4 (SDA) and A5 (SCL), I get an I2C device recognized at 0x03 - and I can use this display without an issue.

So - why am I not satisfied with this result and just use the I2C?
I need to use a RTC unit as well. Not necessarily on the Xiao board in the future. I just need to make sure that one device will use SPI and the other I2C, and the RTC that we have in stock ( a few thousand pieces) are I2C - meaning that the few hundred SPI displays I’ve got in stock will come in handy if I just get them working. :confused:

Anyone that can help me understand what I’m doing wrong here?
According to the manufacturer I should (at least) be able to make the screen work via I2C. That is not the goal here - but it’s a step to make sure the evil little thing works at all.

Anyone with the skills?

Hi, I need more detailed information. For example the link to the item details of the display you purchased and what code you uploaded. We will try to help you check the problem if you are happy to provide it.

Out of curiosity: why?

Hi and thanks for taking the time to answer - I do appreciate your time!

Sure - not a problem at all.
The device (OLED display) I’m using right now is this one (Data sheet on the web site - bottom left corner of the description area):

The following code is just the snippet to try to get the I2C addresses - if they respond at all;

#include <Wire.h>
void setup()
    Serial.println("\nI2C Scanner");
void loop()
    byte error, address;
    int nDevices;
    nDevices = 0;
    for(address = 0; address <= 127; address++ )
        error = Wire.endTransmission();
        if (error == 0)
            Serial.print("I2C device found at address 0x");
            if (address<16)
            Serial.print(address, HEX);
            Serial.println(" !");
        else if (error==4)
            Serial.print("Unknow error at address 0x");
            if (address<16)
    if (nDevices == 0)
        Serial.println("No I2C devices found\n");

And in regards to trying the displays at all, I’ve only managed to get the SSD1306-library demo (“ssd1306_demo”) working with the I2C (four pin) display working, but with the six pin SSD1315 I can’t get it to work as I2C and not as SPI. None of the other demos I’ve tried works unfortunately. These are the ones I’ve tried so far:

  • Adafruit GFX library
  • Adafruit SSD1306
  • ssd1306
  • ssd1306xled
  • U8g2

The ssd1306xled doesn’t seem to be working for Seeeduino Xiao no matter what I do - so that one I uninstalled again, but the rest of them I installed and changed pins where applicable. No luck yet though. Do you need me to send all the demo code as well, or is it possible for you to see them from your end by installing them? I haven’t changed anything except for the pins. That might be the problem ofcourse - but the code seemed too large to send as it’s just a small part which may be of interest in such case.

Tell me if you need more, and I will gladly send it too.


Well - the reason was what I wrote just after the snippet you pasted;

the RTC that we have in stock ( a few thousand pieces) are I2C

Both devices I have needed SDA and SCL on I2C, so I couldn’t find another solution than to have one of them using SPI instead of I2C. Or - was that wrong thinking on my behalf?

You can theoretically have hundreds of I2C devices on the same four pins (SDA, SCL, 3.3, GND). As long as their address is distinct (some devices have the ability to specify few bits in the address) everything should work.
I would use SPI only if I had perf issues, but those display should be reasonably low throughput.

Aaah… That was something I needed to know! Thanks alot!

Well - now I just need to make use of those displays I bought. Hopefully I get them working with I2C at least. Just curious why they are so hard to get up and running. Could the driver for them be the problem - or is it just a matter of connecting them physically and assigning them in the code correctly, you think?

Theoretically I2C is plug and play, but there are factors like device I/O speed which might vary and you might need to experiment. And those are not “drivers”, those are libraries written quite often by third party which are happy to support just what they need.
I wrote one myself for an LCD board, same principle. Not trivial, but once the communication is done it’s pretty much over.

Also, you can have multiple I2C pins if you really need. Hardware is very flexible in this.

:slight_smile: yes - well, It’s a matter of semantics in regards to whether it is a driver or not I suppose. I’ve been developing dynamic link libraries (dll-files, which namely can be drv files as well) for Windows since early 90’s. They are libraries as well (drv, lib and dll files), written with more or less the same intent but is regarded as drivers when they control a hardware and just a class which is used to instantiate a ‘blueprint’ used as business logic, data layer or maybe just as a helper class.

.so in Linux/Unix would be close I suppose.

I do understand libraries - is what I’m trying to say. But I do not know much of the software limitations in Arduino and how these small boards can and cannot be used and the hardware addresses that can or cannot be referenced. I’m exploring. It’s a steep curve at the time! :smile:

Thanks for taking the time to help me! I do appreciate it! :slight_smile:

Sorry if I came across pedantic, it’s just to avoid conveying that the code available is either nicely abstracted or very reliable. Most code around is neither. :slight_smile:

just for fun try using a XIAO expansion board or with groove headers to a grove oled and use i2c

search XIAO Starter Kit

its almost plug and play except for all the commented out configurations you have to figure out

Also i sometimes find information at the seeed XIAO product page there is an image of the pinouts i refer to alot

I am not an expert … Peace

No worries at all, I do understand! And I do appreciate your help! :slight_smile:

Yes, that is a great idea for playing around. Thanks for bringing it up. :+1:

In this case I managed to get the SSD1306 I2C-display working already through. It’s the SSD1315 with either I2C or SPI I will have to get working. I got it responding with an address over I2C, so I think it SHOULD work, but obviously I’m doing something wrong.

Hopefully someone has a trick up the sleeve for this to be solved!

Thank you for your comment though. It is highly valid!

I am having problems with SPI to an RFn24 so i think there is something to know about spi… more wires more problems