3

Question: Is it possible to determine when the SSD1322 OLED driver module is "between redraws" of the screen?

I'm thinking in a similar way to how game consoles/PCs are able to wait until the CRT scanline passes the last line on the screen and returns to the start (something that I assume is 'emulated' on modern screens).

Background: I have a 256x32 pixel OLED display that I'm driving from a Raspberry Pi Pico. I've worked out how to initialise it all and send data to affect the pixels on the display without problems.

I'm planning to have a double RAM buffer in the microcontroller that sends the pixels from the previous frame of an animation stored in one buffer, whilst the next frame is being constructed in the back buffer; common stuff for games consoles/graphics cards.

I'd like to swap which buffer is being displayed at a time when there won't be a tearing effect of half the old buffer being shown and half the new buffer. It isn't vital for the application I'm going for, but I'm a perfectionist.

As far as I understand, the screen is refreshing at 80Hz (based on the initialisation code I found and copied). I'm not sure if that info is any help; in theory if I could accurately switch at a frequency to match the screen, there's still no guarantee that it'll be during periods where no pixels are lit. I'm pretty sure the screen does refresh in a scanline manner, similar to CRTs because of the strobing effect I see when I capture it in slow-motion.

ocrdu
  • 8,705
  • 21
  • 30
  • 42
Mick Waites
  • 43
  • 5
  • What does the datasheet say? – Hearth Nov 23 '21 at 20:22
  • 2
    An SSD1322 appears to have enough internal 'GDDRAM' to support more than 7 screen buffers worth of data for your particular 256 x 32 display. You should be able to do away with double-buffering in your micro and instead use the GDDRAM in the display. Write to address X, then tell it to start displaying from address X, while you write to address Y, then tell it to start displaying from address Y (where X and Y are separated by the size of the required display buffer). – brhans Nov 23 '21 at 20:34
  • @Hearth - nothing that I've found with regards to reading any data/parameters other than the contents of the pixel RAM. – Mick Waites Nov 23 '21 at 21:25
  • @brhans - I'd prefer to write to RAM first before transferring to the display, it avoids having to read data from the display ever and will generally be faster. However, your solution could be the answer assuming the display will not switch to the new source address mid-frame. I will give that a try. – Mick Waites Nov 23 '21 at 21:25
  • @brhans I've tested the start line offset, and it can be used to double buffer the pixel RAM as you suggested, however the switching of it is not synchronised to the screen refresh, so tearing does still happen. Whilst it makes sense to copy the newly rendered frame up to a back buffer on the display, then switch 1 byte to make it visible, I still would like a solution to the tearing if possible. – Mick Waites Nov 23 '21 at 23:21
  • You have a linux driver fbtft that does it for you. I have written mine for SSD1322: https://github.com/MarkoBursic/fbtft---SSD1322 when it wasn't available yet, I guess now you may have supported ones from Notro. – Marko Buršič Nov 23 '21 at 23:46
  • @MarkoBuršič - I'm not really sure how your suggestion will help me, I'm not using Linux and as far as I can see, the driver is about using frame buffers in general (I appreciate that maybe if I can dig into the linux kernel source, it may also prove to be waiting for frame blanks before flipping the buffers - but that would be stretching my abilities a bit much). – Mick Waites Nov 24 '21 at 10:15
  • 2
    I've been through the datasheet, and, strangely, it seems there is no way to get any indication on the current state of the refreshing loop. The only way I can imagine if to hook some circuitry from the SSD1322 COM0 (if you have access to this signal) and bring it to a GPIO of your CPU. But that's ugly. Maybe I missed something, though. – dim Dec 01 '21 at 12:50
  • @dim Thanks for checking the sheet through, from what I can see (and understand) on it, connecting something to COM0 would be tricky, it doesn't seem to be exposed on the ribbon cable at all, so yeah, it would be particularly ugly. – Mick Waites Dec 03 '21 at 09:40
  • 1
    @dim I concur. I wonder if it is because these drivers are derived from the old passive matrix LCD display chips. Those displays had such a slow response rate (~100-200mS) that tearing wasn't an issue. – Jon Dec 08 '21 at 10:41
  • Kind of late to the game here, but curious what you're developing this in. C? MicroPython? (I may have missed it in the comments). Did you import a particular MicroPython library? – Big Owls May 15 '22 at 02:47
  • 1
    This was in C++ and with no 3rd party libs. – Mick Waites May 16 '22 at 14:14

0 Answers0