SH1106 - Transferring long buffer via SPI

Question

I am using an SH1106 and am creating my own driver for it. Nearly everything is doing great with about 2/3ms send time using transfer16. I did notice however that I can use transfer with a buffer and length to give a 1ms display time; something that'd be extremely useful.

For reference before here is the datasheet: http://support.technologicalarts.ca/docs/Components/OLED13-SPI/SH1106.pdf

So the working solution is this:

SPI.beginTransaction(settings);
//
for (int page = 0; page < 8; page++)
{   
    digitalWrite(DC, LOW);
    SPI.transfer(0xB0 + page);
    SPI.transfer(0x02);
    SPI.transfer(0x10);
    digitalWrite(DC, HIGH);

    for (int column = 0; column < 128; column += 2)
        SPI.transfer16(buffer[(page * 128) + column]);
}
digitalWrite(DC, LOW);
//
SPI.endTransaction();

This for each of the 8 pages writes the 128 bytes 2 at a time. I want to write the 128 bytes in a single call. This would be something like this:

SPI.transfer(buffer + (page * 128), 128);

This however sort of inverts the display. It literally turns every pixel on for some reason and I can't figure out why. I am just using a few bytes set to 255 for testing and with the original method this works perfect.

Am I using the call wrong? Is there a limit to the buffer size I could use, I haven't really seen anything about that at the moment. I tried changed the pointer arithmetic but wasn't successful. I tried moving the 128 bytes into a temporary location and use that but still nothing.

Obviously this isn't major and maybe I could somehow improve the transfer in other ways but if you have any advice I'd love to have it

----- EDIT -----

I have had some luck now with using the transfer with buffer method when I changed the page datatype to a uint8_t. It also caused a few more issues however and I am not sure what is causing them.

• Firstly with a fast display rate the display inverts itself once again with all pixels on.
• With a delay between display calls, it works! But after a few seconds those pixels slowly go away, something I have never experienced before.

Here is the edited code:

SPI.beginTransaction(settings);
//
for (uint8_t page = 0; page < 8; page++)
{
    SPI.transfer(0xB0 + page);
    SPI.transfer(0x02);
    SPI.transfer(0x10);

    digitalWrite(DC, HIGH);
    SPI.transfer(buffer + (page * 128), 128);
    digitalWrite(DC, LOW);
}
//
SPI.endTransaction(); 

It's hard to explain whats actually happening. But without a large delay between the calls of the buffer transfer method the screen freaks out and will maybe invert completely if it's too often. Even with the large delay the pixels randomly vanish over time, something I have never actually seen.

The 2 byte send method doesn't have any of these problems. No delay will work fine.

Answer 1

You seem to have understood the following but just for clarification:

transfer16(uint16_t word), as the name implies, shifts 16bits/2bytes instead of just 8bits/1byte like transfer(uint8_t byte).

transfer(uint8_t* buffer, unsigned int size) on the other hand takes a pointer and the amount of bytes to shift.

Now to pointer arithmetic. Operations on pointer variables are dependent on their explicit data type(as well as processor architecture!). Therefore, in our case, a +1 on uint8_t* val will advance the pointer by 8bits. +1 on uint32_t* val will do so by 4bytes/32bits.

Check buffer's data type

It should be any of char, unsigned char, uint8_t, int8_t