5

What's the maximum dotclk frequency for a typical OLED display with serial input? I've looked through some driver specs, example: SEPS525 but its not clear to me. I'm looking to update a small resolution RGB oled (64x64) display at several hundred Hz for a perception/display experiment.

I think my best bet is to drive the dotclk and sync signals, while delivering the data 18 bits wide in serial format.

rbairos
  • 153
  • 4
  • This doesn't make much sense since if the display has "serial input", then there is a driver chip between you and the display. The update rate is between the display and the chip and matters little on the serial side. In any case, the display refresh rate and how fast you can send new information via the serial are two very different things. – Olin Lathrop Mar 28 '13 at 13:54
  • I know there are a few requirements involved, and all are necessary: 1) Whats the maximum dotclk frequency supported by the SEPS525? 2) At what rate does the SEPS525 transfer its contents to the display? 3) What are the physical switching characteristics of a typical low resolution OLED display pixel? Any insight on any of these will help me determine if my request is achievable, or completely off the mark. Thanks. – rbairos Mar 28 '13 at 13:58
  • You should be able to find this between the driver chip datasheeet and the OLED datasheet. If it's not in those, then we'd be just guessing anyways. – Olin Lathrop Mar 28 '13 at 14:08
  • I read through the SEPS525 a/c characteristics. Its not entirely clear. Their A/C timing diagrams for 'serial interface' only applies to SPI (and seems slow for the number of serial bits required). The 4‐4) External Clock Input Timing, I assume applies to the dot-clk but all its ratings are 'TBD' – rbairos Mar 28 '13 at 14:39

1 Answers1

2

Almost none of the prefab display modules I've seen on the market give a "user" any significant control over when information is actually displayed; many don't even let the user know when information will be displayed. The normal design pattern is for the module to accept data from the user into a buffer at times of the user's choosing, and then display the contents of that buffer at a time of the module's choosing. In cases where both the module and the eyes of anyone looking at it are stationary, having the time between when data is fed to the module and when it appears on screen arbitrarily vary between 0-15ms won't be a problem. If the module or the user's eyes are moving, however, the scanning behavior may become quite relevant.

For a 64x64 module, I would expect that it should probably be possible to supply the module with a new frame's worth of data on every scan cycle; if you're interested in controlling or at least knowing exactly when things are displayed, however, you'll have to check the data sheets of any specific modules you're considering to see what sort of control you can get. I wouldn't say that modules "typically" give any control, but some might let you program a frame rate or scanning pattern that would fit your needs even if you have to do some trickery to achieve such behavior (e.g. if the module scans one line every 100us, allows a programmable number of scan lines, and counts scan lines with a down-counter that's reloaded when it hits zero, and if one wanted a frame rate of exactly 125Hz, one could have the scan-line count register programmed with a value of 81 for 7.809ms and a value of 80 for 101us. The timing on the module would then drift until the start of frame coincided with the time when the screen was programmed for 80 lines.

supercat
  • 45,939
  • 2
  • 84
  • 143
  • thats some great advice thanks. It leads me to think the amount of control Id have would be insufficient for the display rates Im looking at. (4khz) I know the TI DLP develpment boards allow these rates for 1 bit high definition images, but was interested in a cheaper smaller OLED implementation. That being said, what would be physically involved in replacing an OLED display with a custom front end driver? ie. Do manufacturers even provide OLED displays without the driver, or do the 200+ pin counts require some pcb base always? Thanks – rbairos Mar 28 '13 at 16:40
  • sorry that should be 2khz, not 4khz frame rate. – rbairos Mar 28 '13 at 16:56
  • Consider that the standard frame rate for displays with VSYNC/HSYNC/DOTCLK interface is 60Hz and most (if not all) controllers won't go much faster than that. And a display with MCU interface (which is the typical case for small displays) is MUCH slower. Replacing the controller is also usually not possible without large and expensive factory equipment, and a manufacturer will probably only sell you the raw OLED in high volumes. – fceconel Mar 28 '13 at 17:29
  • Well the pixel clock rate I need is only about 8mhz, in comparison to low resolution VGA which begins around 30MHZ so Im assuming its not a problem of bandwidth, just one of access to timing sequences. In my fantasy, raw oleds are available with a high density connector available for FPGA interfacing. – rbairos Mar 28 '13 at 17:49
  • @rbairos: I wouldn't expect to find a raw OLED, but you might find something that expects the scanning clock to be supplied externally. Even if a device would typically expect to be used with a scanning clock of e.g. 250Khz (for a ~60Hz display) it's possible the device might tolerate a faster clock (and simply scan the display faster if given one). Not sure how to find a device that could be used like that, though. – supercat Mar 28 '13 at 20:45
  • Just a quick follow up. Scanning through oled driver: SSD1335 Maximum frame rate is: fosc / (clock divide ratio * display_clocks_per_row * multiplex_ratio) Looking at the specs, best case might be: 1.6Mhz / (1 * 91 * 15) = 1172 frames. Theres also a tearing function to synchronize mpu update with display refresh. That looks very promising. – rbairos Apr 01 '13 at 15:30
  • 1
    @rbairos: If 1.1Khz would be a fast enough frame rate for your purposes, you may be all set. What's called a "tearing function" is typically a means of letting the CPU know what the display is doing. Normal usage is to wait until the bottom half of the display is being scanned, draw the top half, wait until the top half is being scanned, and draw the bottom. Such a design was used in Eugene Jarvis' arcade machines (Defender, etc.) starting in the late 1970's; I don't know if any earlier microprocessor-based systems used it. – supercat Apr 01 '13 at 15:34
  • one concern though: im confused by their definition of mux, multiplexing. I was hoping it meant the number of addressable rows that are active at one time, and not a subset of all rows that are sequenced. ie. 15 rows at 1khz frame rate would not work :( – rbairos Apr 01 '13 at 15:38
  • yah, looks like setting mux ratio lower = fewer rows displayed. perhaps i can find a high resolution driver with faster tolerances and use 64 rows – rbairos Apr 01 '13 at 15:49