SSD1306 OLED commands and operations + screen scrolling transition

[alvinhochun]

Hi @Ralim, this is for you:

I'm trying to understand the OLED control a little bit better. I'm referring to the 96x16 display module datasheet on the PINE64 wiki and this SSD1306 datasheet.

1. I tried to comment the REFRESH_COMMANDS data. Is this correct?

const uint8_t REFRESH_COMMANDS[17] = {
    // Set display ON:
    0x80,
    0xAF, // cmd

    // Set column address:
    //  A[6:0] - Column start address = 0x20
    //  B[6:0] - Column end address = 0x7F
    0x80,
    0x21, // cmd
    0x80,
    0x20, // A
    0x80,
    0x7F, // B

    // Set COM output scan direction (normal mode, COM0 to COM[N-1])
    0x80,
    0xC0,

    // Set page address:
    //  A[2:0] - Page start address = 0
    //  B[2:0] - Page end address = 1
    0x80,
    0x22, // cmd
    0x80,
    0x00, // A
    0x80,
    0x01, // B

    // Start of data
    0x40,
};

Seems to me that this can be replaced by a struct with the same memory layout so that the command values can be modified directly instead of using byte array indexing. Do you think this makes sense? Actually, it doesn't look clearer at all...

2. If I want to implement vertical scroll (RE make menu even clearer by using more animations #892), does it make sense to send 4 pages of data (i.e. 2 screens) to the OLED and use the "Set Display Offset (0xD3)" to perform the scrolling? Because animating vertically by manipulating the framebuffer involves a lot of bit shift operations and that's probably not very nice. Obviously, sending 2 screens means it will take double the amount of time to write the OLED data.

   Wait, actually I don't need to send two screens, I can just increase the "page start" and "page end" addresses by 2 and write the framebuffer there instead, because the old screen data is already in the OLED RAM and I don't need to resend it. It looks like this should work nicely, right?

   Addendum: Implemented in Impl. menu item scroll down animation #952

3. Thinking of ways to do the horizontal scrolling without needing to memcpy the whole framebuffer on each frame, but there doesn't look like to be a way to directly set the current column address. (If I can directly change the column address, then I only need to update one column, i.e. two bytes, per frame.)

   There is a hardware horizontal scrolling function, but it doesn't look like it can be applied here.

   (I guess there isn't really any need to accelerate the horizontal scroll anyway...)